Школа
системного анализа
и проектирования
системного анализа
и проектирования
Systems Education
Школа системного анализа
и проектирования
Школа системного анализа
и проектирования
ГЕОРГИЙ САВЕЛЬЕВ
Как разработать
бизнес-требования
Модель выявления требований
Давайте поговорим о том, откуда берутся требования. И бизнес-требования (БТ), и нефункциональные требования напрямую вытекают из потребностей бизнеса.
Напомним, что нефункциональные требования (НФТ) определяют свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.
Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.
Культурные образцы — это те требования, которые можно получить на основе стороннего опыта. То есть, изучая какой-то аналогичный готовый продукт на рынке, мы можем сформировать требования к своему продукту (даже если эти требования никто из стейкхолдеров не озвучивал напрямую).
Все виды требований возникают в конкретном контексте, то есть следуют из Операционного контекста, к которому относятся активы, спрос, технологии и так далее. Подробнее про влияние контекста на бизнес-требования смотрите в статье Бизнес-требования. Назначение.
В наглядном виде модель выявления требований представлена на схеме:
Напомним, что нефункциональные требования (НФТ) определяют свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.
Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.
Культурные образцы — это те требования, которые можно получить на основе стороннего опыта. То есть, изучая какой-то аналогичный готовый продукт на рынке, мы можем сформировать требования к своему продукту (даже если эти требования никто из стейкхолдеров не озвучивал напрямую).
Все виды требований возникают в конкретном контексте, то есть следуют из Операционного контекста, к которому относятся активы, спрос, технологии и так далее. Подробнее про влияние контекста на бизнес-требования смотрите в статье Бизнес-требования. Назначение.
В наглядном виде модель выявления требований представлена на схеме:
Модель выявления требований
Почему важно выявлять и документировать
бизнес-требования?
бизнес-требования?
Бизнес-требования играют важную роль на проекте, поскольку помогают определить смысл проекта и обосновать его необходимость. Именно бизнес-требования, как правило, используются для определения рамок проекта, то есть входят в состав концепции проекта.
Ввиду своей понятности всем заинтересованным лицам, бизнес-требования служат артефактом, на основе которого удобно заключать договоренности. Чем ниже уровень требований, тем больше нюансов, а значит, сложнее договариваться.
Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.
Также бизнес-требования часто используются на проекте для приоритизации решений: если есть понимание, как то или иное решение связано с БТ, приоритизировать его не составит труда. Именно БТ являются снованием для принятия решений в ходе проектирования и внесения изменений в реализацию проекта.
Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.
Ввиду своей понятности всем заинтересованным лицам, бизнес-требования служат артефактом, на основе которого удобно заключать договоренности. Чем ниже уровень требований, тем больше нюансов, а значит, сложнее договариваться.
Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.
Также бизнес-требования часто используются на проекте для приоритизации решений: если есть понимание, как то или иное решение связано с БТ, приоритизировать его не составит труда. Именно БТ являются снованием для принятия решений в ходе проектирования и внесения изменений в реализацию проекта.
Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.
Программа переподготовки
«Business Analyst Bootcamp»
Курс для тех, кто хочет сменить профессию и начать работать в ИТ с хорошими перспективами, занимаясь исследованием задач и проблем бизнеса и постановкой задач на автоматизацию
Какие бывают бизнес-требования?
Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.
Исходя из определения Six Sigma, классификация требований будет опираться на критичные активности, т. е. бизнес-требования могут быть связаны с:
Исходя из определения Six Sigma, классификация требований будет опираться на критичные активности, т. е. бизнес-требования могут быть связаны с:
- Определением значимых характеристик продуктов или услуг.
- Распознаванием и обработкой событий.
- Принятием решений (своевременность, правильность).
- Сбором, обработкой, хранением и предоставлением информации.
- Обеспечением возможности выполнения действий (субъект, действие, объект, время, условия, способ).
- Предотвращением возможности выполнения действий (субъект, действие, объект, время, условия, способ.
Ниже приведены примеры бизнес-требований по видам критичных активностей.
Вид БТ: Значимые характеристики продуктов или услуг
Примеры БТ:
Вид БТ: Распознавание и обработка событий
Примеры БТ:
Вид БТ: Принятие решений
Примеры БТ:
Примеры БТ:
- Скорость обслуживания — очередь на кассе должна быть не длиннее 4 покупателей.
- Своевременность доставки — клиент должен получить пиццу горячей и не умереть ожидая её.
- Простота получения услуги — оформление предварительно одобренного кредита должно завершаться за одно посещение клиента.
Вид БТ: Распознавание и обработка событий
Примеры БТ:
- Банк должен своевременно получать оповещения о сбоях в работе банкоматов.
- К моменту начала этапа работ, все нужные материалы и оборудование должны находиться на объекте строительства и быть готовыми к использованию.
- Сотрудники должны быть своевременно проинформированы о назначенных им задачах.
Вид БТ: Принятие решений
Примеры БТ:
- По каждому обнаруженному дефекту, на основе имеющейся информации, должно быть оперативно принято решение о способе его устранения в соответствии с протоколом реакции на аварийные ситуации.
- Решение о выдаче кредита должно приниматься на основании…
- Отпускная цена на товар для конкретного клиента определяется на основании… в зависимости от …
Вид БТ: Сбор, обработка, хранение и предоставление информации
Примеры БТ:
Вид БТ: Обеспечение возможности выполнения действий
Примеры БТ:
Вид БТ: Предотвращение возможности выполнения действий
Пример БТ:
Примеры БТ:
- С момента обнаружения дефекта и до его полного устранения должна регистрироваться и храниться следующая информация.
- Инвестиционный банк в конце каждого рабочего дня должен направлять Регулятору информацию о…
- Для принятия решений об участии в тендере необходимы результаты предварительной оценки себестоимости проекта.
Вид БТ: Обеспечение возможности выполнения действий
Примеры БТ:
- В случае неудовлетворенности качеством обслуживания, клиент должен иметь возможность направить жалобу по телефону, по электронной почте или через сайт компании.
- Клиент должен иметь возможность отказаться от заказа до момента его отправки.
- Покупатели должны иметь возможность оформить и оплатить покупку самостоятельно посредством мобильного приложения.
Вид БТ: Предотвращение возможности выполнения действий
Пример БТ:
- Должна исключаться возможность доступа к защищенным ресурсам лиц, не являющихся сотрудниками компании.
На данный момент в профессиональных сообществах аналитиков ведутся активные дискуссии по поводу требований, сформулированных в негативной форме. Считается, что абсолютное большинство этих требований можно и нужно переформулировать в позитивную форму — это снизит риск непонимания.
Требование, заданное с позиции «Система должна делать…», задает конкретное направление действиям разработчика, а также даёт некоторые ограничения — в отличие от формулировки требований с позиции «Система не должна…»
Но, конечно, существуют ситуации, когда необходимо сформулировать требования именно в негативной форме и, чаще всего, это касается решения задач безопасности.
Требование, заданное с позиции «Система должна делать…», задает конкретное направление действиям разработчика, а также даёт некоторые ограничения — в отличие от формулировки требований с позиции «Система не должна…»
Но, конечно, существуют ситуации, когда необходимо сформулировать требования именно в негативной форме и, чаще всего, это касается решения задач безопасности.
Признаки проблем в бизнес-требованих
Можно выделить несколько типичных признаков проблем с бизнес-требованиями.
- Неконкретность (слишком абстрактная формулировка)
- Невозможность проверки (нет понимания, что является индикатором выполнения требования)
- «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
- Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
- Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
- Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
- Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
- Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
- Привязка к конкретному решению, в том числе — конкретный бизнес-процесс
Хотелось бы сделать акцент на работе с «Магическими числами», поскольку зачастую такие ошибки в требованиях встречаются даже у опытных аналитиков.
Работа с «магическими» числами
Чтобы проверить требование на наличие данной проблемы, можно определить чувствительность (столбец «чуть-чуть» в таблице) требования и его границы (столбец «гораздо» в таблице).
Чтобы проверить требование на наличие данной проблемы, можно определить чувствительность (столбец «чуть-чуть» в таблице) требования и его границы (столбец «гораздо» в таблице).
Для успеха проекта важно своевременно обнаруживать некорректные требования и решать, что с ними делать.
Для тестирования бизнес-требований на «магические числа» можно использовать модель, представленную на рисунке.
Любое число (разместим его в центральном круге) проверяется на чувствительность (на рисунке это столбец «чуть-чуть»). Что будет, если число будет немного больше? Есть ли какие-то последствия в таком случае для системы, стейкхолдеров? А если число будет чуть-чуть меньше?
Затем мы задаем вопросы, пытаясь выявить реальные границы требования. Что, если число будет значительно больше? На что это повлияет? А если влияние достаточно серьезно, то нельзя ли предложить дополнительный способ обойти проблему? Границы обозначены в модели как столбец «гораздо».
Любое число (разместим его в центральном круге) проверяется на чувствительность (на рисунке это столбец «чуть-чуть»). Что будет, если число будет немного больше? Есть ли какие-то последствия в таком случае для системы, стейкхолдеров? А если число будет чуть-чуть меньше?
Затем мы задаем вопросы, пытаясь выявить реальные границы требования. Что, если число будет значительно больше? На что это повлияет? А если влияние достаточно серьезно, то нельзя ли предложить дополнительный способ обойти проблему? Границы обозначены в модели как столбец «гораздо».
Тест «магических» чисел
Расмотрим пример требования, которое содержит «магическое» число:
“
Требование: Сократить среднее время обработки заявки до 14 минут
Проверим это требование на чувствительность. Для этого зададим вопросы:
Проверим границы требования, ответив на вопросы:
Данный тест помогает понять, является ли число «магическим». Если число связанно с какими-то объективными процессами (например, требованиями законодательства), то мы можем определить его чувствительность и границы, а значит появление этого числа в требованиях вполне обосновано.
Если в ходе тестирования обнаружится, что установить чувствительность и границы числа не представляется возможным, такие требования необходимо переформулировать в конкретные условия или относительные величины.
Попробуем переформулировать требование на примере:
- Что будет, если время обработки заявки будет не 14, а 12 минут?
- Что, если увеличить до 14,5 мин? Насколько это критично?
Проверим границы требования, ответив на вопросы:
- Может быть, целесообразно сократить время обработки до 0 минут, т. е. не обрабатывать заявки и перевести клиента на самообслуживание?
- Что будет, если одна заявка будет обрабатываться день? Это плохо? Как это скажется на бизнесе?
Данный тест помогает понять, является ли число «магическим». Если число связанно с какими-то объективными процессами (например, требованиями законодательства), то мы можем определить его чувствительность и границы, а значит появление этого числа в требованиях вполне обосновано.
Если в ходе тестирования обнаружится, что установить чувствительность и границы числа не представляется возможным, такие требования необходимо переформулировать в конкретные условия или относительные величины.
Попробуем переформулировать требование на примере:
“
Исходное требование:
Оповестить надлежащих стейкхолдеров не позднее 5 минут, после наступления события.
Новое требование:
Задержка в оповещении не должна приводить к задержке выполнения определённого действия получателем этого сообщения.
Оповестить надлежащих стейкхолдеров не позднее 5 минут, после наступления события.
Новое требование:
Задержка в оповещении не должна приводить к задержке выполнения определённого действия получателем этого сообщения.
То есть задержка не должна ни на что влиять. Таким образом, мы достигаем некоторой гибкости относительно временных затрат.
Примеры некорректных бизнес-требований
- Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?
- Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесёт сокращение времени обработки заказа?
- Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
- Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
- Внедрить ERP — Кому и зачем это нужно? В чём проблема?
Типовые ловушки аналитика
Проблемы с требованиями, как правило, возникают, когда аналитик попадает в одни и те же типовые ловушки. Вот основные ловушки аналитика при работе с бизнес-требованиями:
Что можно сделать с каждой из этих ловушек?
- Формальность — «пишу, потому что надо здесь что-то написать».
- Узкие рамки анализа — не рассматриваем ничего, что выходит за рамки проекта.
- Превращение в аудит — выясняем всё обо всём «на всякий случай».
- Превращение метода в цель — строгое следование определенному шаблону с превращением средств в цель и потерей основной цели проекта.
Что можно сделать с каждой из этих ловушек?
Как документируются бизнес-требования?
В практике бизнес-аналитика присутствует два основных подхода документирования требований:
1. Монолитно
2. Дробно
Ниже будет приведен шаблон для каждого из этих видов документирования.
1. Монолитно
- Все требования описываются вместе в виде структурированного повествовательного текста.
- Возможны ссылки на элементы требований (цели, метрики, предположения, риски и т. п.).
2. Дробно
- Каждое требование описывается отдельно.
- Каждому требованию присваивается уникальный идентификатор.
- Возможна трассировка к конкретному бизнес-требованию.
Ниже будет приведен шаблон для каждого из этих видов документирования.
Где документируются бизнес-требования?
Стандартом ISO предполагается, что бизнес требования будут отражены монолитно в Спецификации требований стейкхолдеров (StRS). Для этого предусмотрен отдельный раздел Introduction, который включает в себя Business Purpose (цели), Business Scope (границы), Business Overview (обзор бизнеса).
В ГОСТе 34.602−89 предполагается, что бизнес-требования будут описаны также, монолитом, в техническом задании на создание автоматизированной системы. в разделе Назначение и цели создания системы и Характеристика объектов автоматизации.
Если говорить о дробном документировании, то чаще всего это подходы, подразумевающие использование Спецификации бизнес-требований (BRD).
В Agile бизнес-требования могут быть отражены по-разному. Это не формализовано, нет стандарта документов и способов описания.
В ГОСТе 34.602−89 предполагается, что бизнес-требования будут описаны также, монолитом, в техническом задании на создание автоматизированной системы. в разделе Назначение и цели создания системы и Характеристика объектов автоматизации.
Если говорить о дробном документировании, то чаще всего это подходы, подразумевающие использование Спецификации бизнес-требований (BRD).
В Agile бизнес-требования могут быть отражены по-разному. Это не формализовано, нет стандарта документов и способов описания.
Шаблон монолитного описания БТ
Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:
- Контекст.
- Описание возможности.
- Бизнес-цели.
- Метрики успешности.
- Образ результата (Vision).
- Деловые риски.
- Предположения и зависимости бизнеса.
Советы Вигерса по описанию БТ
- Сокращайте шаблон в соответствии с потребностями.
- Заполняйте не сверху вниз, а по мере поступления информации.
- Пустой раздел — признак его ненужности или необходимости дополнительного изучения.
- Не повторяйте то, что уже описано в другом месте — сошлитесь на имеющееся описание.
- Исходите из возможности повторного использования БТ в других проектах.
- Выявляйте конфликты, противоречия и выносите на обсуждение.
- Проводите повторное рассмотрение БТ при каждой смене лиц, принимающих решения, чтобы убедиться, что понимание БТ не изменилось
Шаблон дробного описания БТ
Ниже представлен авторский шаблон дробного описания бизнес-требований. Он состоит из нескольких ключевых элементов:
1. Заголовок, который включает в себя:
- Уникальный идентификатор.
- Краткое описание.
3. Источник, откуда это требование взялось.
4. Зависимости, если они есть между другими требованиями.
5. Обоснование, краткое пояснение мотивации.
6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.
Шаблон дробного описания БТ
Как документировать —
объединять или дробить?
объединять или дробить?
Для того чтобы определиться с тем, как документировать, придерживайтесь следующих правил:
1. Нет нужды документировать, если:
1. Нет нужды документировать, если:
- Узко-технический проект небольшого объема.
- Всем все понятно и вряд ли кому-то когда-то что-то будет непонятно.
- Компактный проект с узкими целями.
- Узкая предметная область.
- Бизнес-требования умещаются на паре страниц.
- Много бизнес-требований.
- Сложные бизнес-требования.
- Могут реализовываться по отдельности.
- Высокая степень неопределенности.
Что делать с отсутствующими или плохими БТ?
Прежде всего стоит пересмотреть уже имеющиеся требования, разобраться в их назначении и перепроектировать при необходимости. Подобное фундаментальное переосмысление бизнес-процессов называется реинжиниринг.
Далее необходимо выяснить больше информации об этих требованиях. Сделать это можно посредством анализа документов, наблюдения, а также провести интервью, использовать метод пяти почему или бенчмаркинг (наблюдение за людьми в аналогичных организациях).
Полученную информацию необходимо задокументировать одним из нескольких способов:
1. Создать отдельный документ. Например, «Каталог целей» с дробным документированием бизнес-требований, на которые будем ссылаться.
2. Добавить комментарии к уже существующим требованиям, поясняя откуда оно взялось.
3. Собрать все непонятные требования в один документ и в начале этого документа вставить раздел Мотивация. В этом разделе необходимо указать, для чего нужно все то, что мы выяснили.
4. В конце готового документа требований добавить приложение Обсуждения и договоренности. В процессе заполнения разбить его на тематические разделы по бизнес требованиям и внести в них все договоренности с присвоением идентификаторов, на которые в последствии можно будет ссылаться в тексте самого документа.
Далее необходимо выяснить больше информации об этих требованиях. Сделать это можно посредством анализа документов, наблюдения, а также провести интервью, использовать метод пяти почему или бенчмаркинг (наблюдение за людьми в аналогичных организациях).
Полученную информацию необходимо задокументировать одним из нескольких способов:
1. Создать отдельный документ. Например, «Каталог целей» с дробным документированием бизнес-требований, на которые будем ссылаться.
2. Добавить комментарии к уже существующим требованиям, поясняя откуда оно взялось.
3. Собрать все непонятные требования в один документ и в начале этого документа вставить раздел Мотивация. В этом разделе необходимо указать, для чего нужно все то, что мы выяснили.
4. В конце готового документа требований добавить приложение Обсуждения и договоренности. В процессе заполнения разбить его на тематические разделы по бизнес требованиям и внести в них все договоренности с присвоением идентификаторов, на которые в последствии можно будет ссылаться в тексте самого документа.
Программа переподготовки
«Business Analyst Bootcamp»
Курс для тех, кто хочет сменить профессию и начать работать в ИТ с хорошими перспективами, занимаясь исследованием задач и проблем бизнеса и постановкой задач на автоматизацию
Вопросы и ответы
- Вопрос:Что делать, если, помимо ТЗ, есть еще и пользовательские требования?Ответ:Зачастую пользовательские требования объединяются с бизнес-требованиями, т.к. объем БТ не очень большой, если они правильно определены, а значит делить эти требования на 2 отдельных документа нецелесообразно.
Во избежание возможного недопонимания, в названии документа можно явно указать «Требования бизнеса и пользователей». - Вопрос:Имеет ли смысл создание промежуточных документов таких как VSD (Vsion & ScopeDocument) и BRD (Business Requirement Document)?Ответ:С точки зрения Agile практик, бизнес-требования — это епархия Product Owner. Следовательно, работать нужно так, как удобно, и не создавать лишних документов для соблюдения формального протокола. Чем документов меньше, чем они компактнее и проще, тем эффективнее.
- Вопрос:Должны ли в описание БТ быть включены требования к описанию «хотелок» в части User Interface?Ответ:Отрицать «хотелки» или указывать стейкхолдерам на их неуместность — не всегда хорошо. Поэтому можно написать требования так, как считаете нужным, а в примечании написать комментарий для разработчиков с пожеланиями конкретного стейкхолдера относительно реализации данного требования.
- Вопрос:Обязательно ли современному аналитику владеть навыками программирования?Ответ:Не обязательно, но желательно. Чем шире кругозор аналитика, чем больше диапазон его возможностей, тем от более эффективным он будет выполнять свою работе и продвигаться по карьерной лестнице.
- Вопрос:Должен ли аналитик просматривать баги проекта и принимать решения о их важности?Ответ:Иногда аналитик должен просматривать баги, а иногда - нет. Зависит от договоренностей в рамках проекта и распределения ролей в команде.
Что касается принятия решений о важности, то чаще всего их принимает аналитик. Но стоит помнить, что не всегда стоит загружать аналитика рутиной работой, т.к. из всех обнаруженных багов 80% не требуют, чтобы их прогоняли через формальный процесс, потому что и так всем понятны. - Вопрос:Должен ли аналитик проводить тестирование и валидацию продукта?Ответ:К функциям бизнес-аналитика относятся определение критериев приемки и оценки для продукта, поэтому они часто участвуют в приемо-сдаточных испытаниях и могут разрулить какую-то ситуацию. Т.е. аналитик не должен проводить тестирование, но хорошо, когда он участвует в приемо-сдаточных испытаниях.
- Вопрос:Что является объектом требований вида «Должна собираться информация о недоступности банкомата» — к чему это бизнес требование? К организации? Подразделению? К бизнес-процессу?Ответ:Это требование бизнеса, объектом является банкомат, которым мы должны управлять. Управление состоит в том, что мы умеем различать его состояния, умеем отслеживать то, что с ним происходит, умеем реагировать на эти события и изменять состояния объекта управления, т. е. банкомата. Получается, это бизнес-требование, связанное с необходимостью и способностью организации управлять определенными типами объектов (например, банкоматами).
- Вопрос:Что делать с функциями, если они не мапятся на конкретное БТ или мапятся сразу на два (при этом функция должна быть в скоупе)?Ответ:Важно понимать, для чего мы делаем трассировку. В данном случае мы делаем трассировку, чтобы понять — БТ выполняется или нет?
Нам не важно замапить все на все. Если мы делаем трассировку к модулям, это не значит, что нам надо оттрасировать каждую функцию и каждое требование. Достаточно понимать, данное требование — оно выполнено или нет? Если понимания достигнуто, то дальше можно не трассировать. Если мы пытаемся оттрасировать в другую сторону и видим какую-то висячую функцию, то это не значит, что у нас не должно быть никаких висячих функций, которые мы не можем замапить на какую-то функцию.
Стоит помнить, что трассировка — это инструмент, а не цель.
Автор
Георгий Савельев
Эксперт по бизнес-анализу, член Международного института бизнес-анализа (IIBA), первый CBAP в России. Соавтор BABOK v.3. Вице-президент IIBA Russian Chapter.
Имеет 20-летний опыт работы в качестве бизнес-аналитика, архитектора решений, консультанта и тренера в сфере производства и дистрибуции FMCG, складской и транспортной логистики, управления продажами, дорожного строительства, металлургии, нефтедобычи, гостиничного бизнеса, занятости, здравоохранения.
Участвовал в реализации более 50 проектов по разработке, внедрению и совершенствованию программного обеспечения.
С 1990 года занимается проведением тренингов и деловых игр для руководителей и специалистов. Автор статей по бизнес-анализу.
Создатель авторских аналитических методик и моделей оперативного планирования. Участвовал более чем в 20 консалтинговых проектах по увеличению прибыльности и совершенствованию операционной эффективности компаний.
Участник профессиональных ассоциаций IASA, ABPMP Russian Chapter.
Участвовал в реализации более 50 проектов по разработке, внедрению и совершенствованию программного обеспечения.
С 1990 года занимается проведением тренингов и деловых игр для руководителей и специалистов. Автор статей по бизнес-анализу.
Создатель авторских аналитических методик и моделей оперативного планирования. Участвовал более чем в 20 консалтинговых проектах по увеличению прибыльности и совершенствованию операционной эффективности компаний.
Участник профессиональных ассоциаций IASA, ABPMP Russian Chapter.
Другие статьи: