Требования к проектам бизнес-аналитики

Роль бизнес-аналитика в современной коммерческой организации

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

Можно выделить четыре основные группы требований:
1) требования бизнеса;
2) требования заинтересованных сторон;
3) требования решения;
4) переходные требования.

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

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

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

Таким образом, бизнес-аналитик — это специалист, который призван помогать компании устойчиво развиваться, формируя новые или совершенствуя существующие направления деловой активности, основные и вспомогательные бизнес-процессы в соответствии с ее стратегическими целями и запросами стейкхолдеров. Очевидно, что в российских условиях это вполне вписывается в концепцию модернизации и инновационного развития, реализуемую на уровне хозяйствующих субъектов.

Бизнес-аналитик призван на основе изучения бизнес-процессов предприятия осуществлять их моделирование, корректировку, совершенствование и перестройку.

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

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

Более подробное описание роли бизнес-аналитика в современной коммерческой организации Вы можете узнать в учебном пособии «Основы бизнес-анализа», см. источник для статьи.

Источник для статьи

Основы бизнес – анализа: учебное пособие. В.И. Бариленко. – М.: КНОРУС, 2013.

Требования к проектам бизнес-аналитики

Я отработал 1,5 года в большой большой компании, которая занимается оптовыми и розничными поставками нефте-газового оборудования (оборот около 30ккк рублей). Внутри внедрена система управления (разработана на 1С), включающая несколько конфигураций для нескольких бухгалтерий, складов и т.д. Около 2к пользователей, работающих в системе ежедневно.

Поддерживает и развивает всю систему команда аналитиков. За это время у нас выработались правила, которые, по моему мнению, помогут всем аналитикам (бизнес, требований) и менеджерам, сотрудникам поддержки и даже немного разработчикам в крупном enterprise сегменте.

1. Аналитика ноги кормят

Это правило придумал мой коллега. Если вы находитесь в одном здание с пользователями и ключевыми заказчиками, то их надо посещать и разговаривать с ними. Так как не все умеют четко и ясно выражать свои мысли письменно, иногда один 15 минутный разговор может заменить трехдневную переписку.

Игнорирование этого правила приведет к долгим почтовым перепискам и бесконечной формализации задач.

Рисование схем бизнес-процессов и набросков интерфейса позволит понять задачу вам и легко объяснить свое виденье пользователю. Красивые схемы бизнес процессов производят огромное впечатление на руководство заказчика. Лично я использовал нотацию EPC с вольными добавками (достаточно просто для понимания и достаточно наглядно).

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

3. Упрощайте (или не усложняйте)

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

Где-то через год работы я понял, что думать надо по следующему алгоритму:

а) придумаем простое решение;
б) пытаемся выяснить почему не подходит;
в) немного усложняем;
г) пытаемся выяснить почему не подходит;
д) немного усложняем;
и т.д. пока решение не станет оптимальным.

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

4. Опрашивайте всех будущих пользователей и всех участников процесса

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

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

5. Докапывайтесь до сути проблемы

Пользователи постоянно просят какие-то кнопки на формах, какие-то фильтры на списках и не любят объяснять зачем. Но выяснив ответ на вопрос «Зачем?» вы можете придумать совершенно другое решение, которое возможно будет работать лучше и эффективней.

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

6. Решайте глобальные задачи

Например, вас просят сделать документ, чтобы включить отдел в процесс работы в вашей ERP системе. На основании этого требования вы должны ставить глобальную задачу «Автоматизация отдела плано-экономического отдела» и выяснять смежные требования, но и докапываться до сути, согласно правилу 5. Это поможет сразу разработать решение, которое в будущем вызовет меньше доработок.

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

7. Пользователь нацелен на успех (результат)

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

Игнорирование этого правила приведет к развитию конфликтов.

8. Принимайте универсальные решение (не автоматизируйте автоматизированное)

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

Игнорирование этого правила приведет к лишнему расходованию ресурсов.

9. Исполнитель должен понимать, что он делает

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

Игнорирование этого правила приведет к плохим решениям с точки зрения разработки.

10. Избегайте неоднозначности

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

Игнорирование этого правила приведет к решения не отвечающим задачам.

Становление аналитика

Аналитики — кто это?

По большому счету в сфере ИТ можно выделить два вида их специализации:

  • Системные аналитики
  • Бизнес-аналитики (данная роль относится не только к ИТ).

Несмотря на то, что решаемые задачи и требуемые навыки у них существенно различаются, на ИТ-проектах в большинстве случаев обе эти роли объединяет в себе один сотрудник (или группа сотрудников). Разделение иногда встречается (например, обычно на проектах для финансовых организаций), но такие случаи в меньшинстве.Формальные определения без труда гуглятся, а по сути:

  • Главные задачи системного аналитика: сбор, анализ, формализация и согласование требований к системе. Другими словами, управление требованиями на протяжении всего их жизненного цикла. Основной, хотя обычно не единственный, документ на выходе – техническое задание или его аналог. На этом остановимся подробнее ниже.
  • Главные задачи бизнес-аналитика – изучение, описание, анализ и (при необходимости) реинжиниринг бизнес-процессов. Основной документ на выходе – описание бизнес-процессов As Is (обязательно) и To Be (при необходимости).

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

Краткое техническое отступление

Давайте сознательно прервем повествование и остановимся на самих требованиях. Что касается видов, атрибутов, характеристик, подходов к сбору и оформлению требований – пожалуй, большего «бардака» сложно найти. Состав и содержание документов с требованиями существенно различаются (взять, к примеру, наш ГОСТ и RUP, и имхо это не сравнение пушки и рогатки). Набор атрибутов требований так же в каждом подходе приводится свой, часто весьма неоднозначный (например, в BABOK). В довершение, часто путают результаты этапов анализа и проектирования, заставляя исполнителей включать в аналитические документы финальный вид диаграммы классов и полную схему БД (об этом ниже).
Не претендуя на истину в последней инстанции или какое-то ноу-хау (примерно то же написано в Википедии), сформулируем два ключевых способа классификации требований.
По уровню:

  • бизнес-требования. Самые высокоуровневые требования, которые определяют цели создания ПО. Примерами таких требований могут быть достижение 20%-го сокращения издержек или повышение качества управления (например, за счет возможности оперативного формирования отчетности). Данные требования обычно описываются в отдельном документе — «Видении проекта» (Vision) или «Бизнес-требованиях», который так же включает определение основных ролей будущих пользователей. Системы и перечисление ее основных сценариев использования. Если такого выделенного документа нет, то часто все это включается в техническое задание или его аналог;
  • требования пользователей. Они определяют набор пользовательских задач, которые должна решать Система, с описанием сценариев решения данных задач. Требования пользователей обычно представляются в виде перечисления вариантов использования Системы и взаимосвязей между ними (как правило, в виде Use-case диаграммы языка UML).Сами варианты использования описывается в виде составляющих их последовательностей действий со всеми возможными пред/постусловиями и ветвлениями. Часто описание является текстовым (эта тема хорошо описана в книге Алистера Коберна » Современные методы описания функциональных требований к системам «);
  • функциональные требования. Детально описывают все элементы функционала, который должен быть непосредственно реализован в Системе, чтобы обеспечить возможность выполнения всех сценариев использования, описанных в Требованиях пользователей. Функциональные требования являются наиболее детализированными. Они описывают, в том числе, входные/выходные данные и их проверки, алгоритмы обработки данных и элементы пользовательского интерфейса (без дизайна). Как правило, данные требования оформляются в виде отдельного документа («Технического задания» и т.д.). В этом же документе детализируются сценарии использования Системы (Требования пользователей), к которым обычно и привязываются функциональные требования. Пример функционального требования: по клику на кнопке на форме должно отображаться модальное диалоговое окно, содержащее . По типу: функциональные требования описывают непосредственно функционал, реализуемый Системой (пример приведен выше в описании классификации требований по их уровню в пункте «Функциональные требования»);
  • ​нефункциональные требования. Описывают характеристики системы и ее окружения, а так же накладываемые ограничения. Примерами нефункциональных требований могут служить ограничения на поддерживаемые разрабатываемой Системой аппаратные платформы и операционные системы, а также требования к производительности, к безопасности и т.д.

Примечание. Как видно из описания, приведенного выше, функциональные требования – это категория требований как по их уровню, так и по их типу. К сожалению, в настоящий момент сложилась именно такая неоднозначная терминология (по опыту многих проектов и нескольких работодателей). Если у вас есть другие подходы, пожалуйста, поделитесь.Описывать характеристики (непротиворечивость, полноту и т.д.) качественных требований и все их атрибуты (статус, источник и т.д.) здесь не буду, чтобы не раздувать пост. Если эта тема будет интересна, с удовольствием освещу ее в отдельной статье, хотя все это без труда гуглится. По этой же причине не стану описывать здесь статусы/версии/срезы (baseline) требований. Однако хотелось бы остановиться на некоторых базовых принципах работы с требованиями (этот список далеко не полон). Последовательность работ и их результатов. Следует четко различать результаты этапов анализа и проектирования. На этапе анализа формируются требования к Системе. Все детали реализации Системы определяются уже на следующем этапе – этапе проектирования. Таким образом, в случае необходимости включить в «Техническое задание» модель базы данных Системы или диаграммы классов нужно понимать, что в этом случае:

  1. Произойдет смешивание в одном документе результатов различных типов работ, выполняемых разными людьми (аналитиком и архитектором);
  2. Срок сдачи технического задания будет увеличен, т.к. для его завершения потребуются некоторые результаты этапа проектирования. Результаты этапа проектирования эффективнее оформлять в отдельном документе, описывающем архитектуру Системы.

Однако некоторые отступления, такие как включение в «Техническое задание» спроектированных макетов интерфейса (без дизайна/оформления), допустимы, т.к. выполняются теми же людьми, которые разрабатывают само техническое задание. Порядок сбора самих требований:

  1. Сначала выявляются цели создания Системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у Исполнителя не будет возможности контролировать соответствие разработанной Системы тем целям, для которых она создавалась, а также – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;
  2. Далее определяются роли пользователей Системы (как людей, так и других программных систем). После этого выявляются и описываются сценарии использования Системы каждой из данных ролей. Так формируются Требования пользователей.
  3. Далее разрабатывается полный набор требований к функционалу Системы таким образом, чтобы данный функционал позволял выполнить все сценарии, описанные в Требованиях пользователей. Также фиксируются ограничения для Системы и параметры среды ее функционирования.

Отсутствие дублирования в описании требований. Ключевым моментом управления требованиями является отсутствие дублирования, т.е. каждое требование должно быть зафиксировано только в одном документе и только в одном месте данного документа. Отступление от данного принципа приведет как к серьезному увеличению трудозатрат на поддержку данных документов, так и к неизбежному нарушению их целостности (т.к. для сложно программной системы учесть все нюансы всех новых требований параллельно во всех документах является сложной и ресурсоемкой задачей). В случае необходимости, вместо дублирования описаний требований необходимо использовать ссылку на оригинал данного описания. Это позволит как учесть взаимосвязи между требованиями, так и избежать описанных выше проблем.Управление изменениями. При разработке современных программных систем часто требуется внести изменения в требования уже по окончании этапа анализа. Здесь важно, чтобы стороны понимали и принимали следующие принципы:

  • Исполнитель понимает, что требования не всегда могут быть сформулированы Заказчиком полностью и корректно на начальных стадиях проекта. Соответственно, изменения в требованиях по ходу проекта допускаются;
  • Заказчик понимает, что изменение требований влечет за собой увеличение трудозатрат и сроков сдачи продукта.
Другие публикации:  Армения судебные приставы

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

  • ко всем относящимся к разработке ПО материалам;
  • ко всем ключевым носителям информации и лицам, обладающим требуемыми полномочиями

Во втором случае имеются в виду:

  1. заинтересованные лица
  2. эксперты предметной области
  3. лица, участвующим в согласовании и утверждении требований
  4. технические специалисты со стороны заказчика либо других подрядчиков/субподрядчиков.

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

Зачем нужны аналитики? (привет, кэп)

До сих пор от некоторых разработчиков (хотя сейчас уже очень редко) можно услышать, что аналитики (равно как руководители проектов, менеджеры по продукту и т.д.) не только не вносят полезный вклад в дело, но и просто «мешаются под ногами». Лезут, понимаешь, со своими процессами, бумажками и прочей бюрократией — не дают простому девелоперу спокойно работать (смайл). Излишняя бюрократизация конечно зло, но реализовать большой проект «на коленке», да еще усилиями специалистов лишь одного профиля в современном мире нереально. Никто не оспаривает важную роль разработчиков, но будут ли они продавать, оформлять кучу сопутствующей документации, пытаться понять своеобразный язык заказчиков и т.д.? Позволю себе предположить, что вряд ли многих из них это заинтересует. К слову, если бы все вышеназванные товарищи (аналитики, менеджеры и т.д.) были бы обычными дармоедами, их бы в нашем мире жесткой конкуренции не нанимали в таких количествах и не платили бы им таких денег. Оговорюсь только, что речь идет об Enterprise-проектах. Создать успешное мобильное приложение и заработать на нем понятные деньги сейчас (пока еще?) под силу одному человеку. Возвращаясь, собственно, к роли аналитиков. Чтобы не растекаться мыслью по древу, просто перечислю основные моменты, с которыми им приходится сталкиваться в реальных проектах:

  • выслушать заказчика. Иногда уже это бывает непросто – некоторые способны говорить часами буквально ни о чем, и не всегда легко удается перевести общение в конструктив. Тут ключевым является навык активного слушания;
  • понять иногда «птичий» язык заказчика и сформулировать его требования понятным языком, полно и без противоречий. Т.е. превратить поток сознания клиента в набор формализованных требований;
  • в некоторых случаях, когда заказчик «сам не знает, чего хочет», предложить оптимальное решение или «подвести» к нему самого заказчика;
  • проанализировать влияния новых требований на существующую архитектуру и функционал. Здесь часто будут полезны консультации архитектора;
  • задокументировать требования в виде документа или набора документов в требуемом виде. Затем согласовать их и утвердить;
  • завести талоны в системе такс-трекинга и в дальнейшем отслеживать их нелегкую судьбу. Завести может и архитектор или dev. lead по ТЗ, но чаще это делает аналитик;
  • осуществлять верхнеуровневый контроль соответствия реализованного функционала требованиям;
  • управлять изменениями требований;
  • осуществлять все взаимодействие с заказчиками по вопросам требований;
  • часто – участвовать в сдаче продукта заказчику.

Так же аналитиков частенько «припахивают» к не совсем профильным для них задачам, вроде участия в тестировании, внедрении и разработке пользовательской документации. Бороться с этим или смириться – по большому счету личное дело каждого. Более интересной, хоть и тоже не совсем профильной активностью является участие в пресейлах. Кстати, часто эта деятельность бывает весьма увлекательной и развивающей (хотя и чрезвычайно затратной по времени).

Кто и как становится аналитиком (по трудовой)?

Чистых бизнес-аналитиков, вовлеченных в ИТ-проекты, не так много. В большинстве случаев их задачи выполняют системные аналитики. И признаюсь, у меня нет репрезентативной выборки, чтобы судить, откуда они берутся. Что же касается системщиков, просто по опыту: стать аналитиком «сразу» (без опыта предыдущей работы в сфере ИТ) обычно нельзя. По крайней мере, за все время моей работы мне не удалось встретить ни одного такого человека. Видимо это из-за того, что как требования к кандидату, так и ответственность, изначально велики. На практике, в аналитиков часто вырастают успешные тестировщики и, иногда, технические писатели. Так же нередко аналитиками становятся разработчики: кто-то из-за того, что понял, что разработка – это не его, кто-то действительно хочет быть аналитиком, для кого-то это лишь более короткий путь в ПМ-ы.Всего один раз встречал аналитика, выросшего из системного администратора. Здесь не возьмусь делать выводы – опять же слишком маленькая выборка. Так же знаю одного ПМ-а, перешедшего в аналитики, но это скорее исключение.

Что должен знать/уметь аналитик и как этому научиться?

Читавшие упомянутую выше книгу «Путь аналитика. Практическое руководство IT-специалиста», особенно те коллеги, которые только начинают свою карьеру в ИТ, наверняка прифигели несколько удивились тому объему знаний и умений, которые автор предлагает освоить несчастному читателю. Если вкратце, то следуя данной книге, аналитик должен освоить весь накопленный человечеством опыт в данной области со всеми методологиями, техниками и инструментами, а заодно и в максимальной степени обладать всеми положительными личными качествами, присущими человеческим существам. На мой скромный взгляд, там все-таки описан некий сферический аналитик в вакууме идеал, к которому можно (но не факт, что нужно) стремиться. Фанатичное стремление овладеть сразу всеми знаниями и навыками приведет, разве что, в Кащенко. Готов поспорить на бутылку Talisker 16 y.o., (с кем-нибудь одним, а то же, неровен час, найдутся Шелдоны (смайл)), что в природе нет ни одного человека, полностью соответствующего продвигаемому в книге образу (со всем описанным набором знаний и навыков), включая самого автора книги.Не говорю, что предложенные там навыки не важны, просто надо уметь расставлять приоритеты. К слову, для аналитика это ключевое качество. И, что бы я тут не писал, книгу эту несомненно стоит прочитать.Однако, как я уже упоминалось во вступлении, знания и навыки аналитика и способы их приобретения – тема очень большая. И чтобы не раздувать этот пост, не буду пытаться осветить ее здесь подробно. А в если в двух словах, то конечно стоит иметь представление:

  • о жизненном цикле ПО;
  • о нескольких ключевых методологиях разработки (waterfall, RUP, что-то из Agile, лучше бы Scrum, для гос. заказчиков – ГОСТ 19 (на программы) и 34 (на автоматизированные системы));
  • об основах системного анализа (Вигерс отлично подойдет);
  • о нотациях и инструментах проектирования и моделирования (самые востребованные на рынке, пожалуй: Sparx Enterprise Architect и Rational Rose; и UML/Aris/IDEF0 и IDEF3);
  • о теории реляционных БД и т.д.

О необходимости владеть в совершенстве Word-ом или его аналогом даже не пишу (смайл). А вот о необходимости владеть хотя бы одним инструментом для проектирования макетов интерфейсов, стоит упомянуть. Выделенные интерфейс-дизайнеры – редкость, так что эта работа часто «падает» на аналитиков. Здесь кроме очевидного Visio могу посоветовать простой и удобный Evolus Pencil. Плюс, некоторые личные качества, такие как ответственность, коммуникабельность и внимание к деталям, действительно стоит «прокачивать». Для этого есть специальные техники.

IT1410: Разработка требований к программному обеспечению

Бизнес-аналитик — это основное лицо, отвечающее за выявление, анализ, документирование и проверку требований к проекту. Это основной коммуникативный канал между группой клиентов и командой разработчиков (рис. 4-1), хотя, конечно, не единственный: есть и другие. Аналитик отвечает за сбор и распространение информации о продукте, а менеджер проекта — за обмен информацией о проекте.

Рис. 4-1 Обязанности аналитика требований: наведение коммуникативных мостов между клиентом и разработчиками

Бизнес-аналитик — это одна из ролей участников проекта, а не обязательно название должности.

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

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

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

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

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

От таланта аналитика зависит успех проекта. Один из клиентов, которых я консультировал, пришел к выводу, что спецификации с требованиями, созданные опытными аналитиками, удается изучать вдвое быстрее, чем созданные новичками, поскольку в первых меньше недостатков. В модели Cocomo II, широко применяемой для оценки проектов, опыт и способности аналитика требований сильно влияют на материальные и трудовые затраты, связанные с реализацией проекта (Boemn et al., 2000). Привлекая опытных аналитиков, можно на треть снизить связанные с проектом трудозатраты по сравнению с аналогичными проектами, где заняты неопытные аналитики.

IT1410: Разработка требований к программному обеспечению

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

Аналитик — это посредник в общении, проясняющий смутные представления пользователей и обращающий их в четкие спецификации, которыми руководствуется команда разработчиков продукта. В этом разделе описаны некоторые стандартные обязанности аналитика.

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

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

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

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

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

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

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

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

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

Управлять требованиями. Бизнес-аналитик вовлечен во все этапы разработки ПО, его задача — помочь создать, обсудить и осуществить план управления требованиями к проекту. Определив базовую версию требований для текущего выпуска продукта или итерации разработки, бизнес-аналитик переходит к отслеживанию состояния этих требований, проверкой того, как они реализуются в продукте и управлением изменениями базовых требований. Расспрашивая коллег, аналитик собирает информацию о связях требований, сопоставляет их с прочими элементами системы.

Бизнес аналитик: обязанности, требования к деловым и личным качествам, перспективы трудоустройства

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

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

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

Карьера в IT: должность Бизнес-аналитик

Бизнес-аналитик — это специалист, который исследует проблему заказчика, ищет решение и оформляет его концепцию в форме требований, на которые в дальнейшем будут ориентироваться разработчики при создании продукта.

По данным ДОУ, среднему бизнес-аналитику 28 лет, он имеет зарплату $1300-2500 и опыт работы 3 года.

Задачи и обязанности

Главная задача бизнес-аналитика — выявить проблемы бизнеса заказчика и найти максимально эффективное решение. Для этого он должен обладать знаниями в предметной области.

Работа бизнес-аналитика включает такие этапы:

  1. Выявить потребности заказчика, понять проблему, которую он хочет решить.
  2. Самостоятельно или с помощью команды сформулировать концепцию решения.
  3. Оформить концепцию в техническое задание с конкретными требованиями к будущему продукту. Для этого используются различные техники бизнес-анализа — постронение моделей процессов и структур, прототипы пользовательского интерфейса, сценарии использования. В это же время делается точная оценка трудозатрат и длительности работ.
  4. Детализировать каждое требование в виде спецификаций.
  5. Консультировать программистов и тестировщиков во время разработки продукта, спорные моменты обговаривать с заказчиком.
Другие публикации:  Пенсия ребенку инвалиду с апреля 2019

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

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

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

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

В круг обязанностей бизнес-аналитика входит:

  • Анализ бизнес-потребностей заказчика;
  • Составление требований к будущему продукту (общение с заинтересованными лицами — разработчиками, клиентами, конечными пользователями);
  • Анализ требований (применение различных методологий и нотаций — прототипирование, анкетирование, опрос, мозговой штурм, анализ существующих документаций, конкурентов);
  • Анализ проблемных областей и предложения для улучшения;
  • Формализация требований (разделение требований на бизнес-, функциональные, не функциональные, написание спецификации требований);
  • Управление требованиями (обработка запросов на изменение, анализ и описание влияния на существующие требования);
  • Трансляция требований между разработчиками и клиентом.

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

Типичный рабочий день бизнес-аналитика — это:

  1. Митинги с проектной командой и с заказчиком;
  2. Проработка концептуальных решений;
  3. Работа с инструментами анализа: схемами, диаграммами, моделями, прототипами;
  4. Работа с требованиями: сбор, написание ТЗ и спецификаций;
  5. Консультации разработчиков и тестировщиков;
  6. Изучение стандартов.

Достоинства и недостатки

Главное преимущество профессии бизнес-аналитика — возможность проникать в суть: разбираться, что как устроено, из каких частей состоит, как они между собой связаны и взаимодействуют, и затем описывать сложные вещи с помощью простых, но полезных моделей.

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

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

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

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

Как стать бизнес-аналитиком и куда идти дальше?

Можно выделить 2 пути становления:

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

Часто аналитики вырастают из тестировщиков. Проделавшие такой путь специалисты знают „внутреннюю кухню“ IT и имеют материал для того, чтобы отличать хорошо написанные требования от плохо написанных.

Для работы бизнес-аналитика важно:

  1. знать методологии сбора, анализа и формализации;
  2. знать предметную область, которую нужно анализировать;
  3. понимать жизненный цикл ПО в соответствии с различными методологиями;
  4. знать основы программирования, тестирования, алгоритмов, экономики.

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

Что касается личных качеств, необходимо:

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

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

Также желателен общий технический бекграунд — или опыт в IT, или технический ВУЗ.

Перспективы карьерного развития бизнес-аналитика:

  1. Совершенствоваться как аналитик, осваивать все больший круг аналитических задач.
  2. Углубиться в системную составляющую и стать Business или Enterprise Architect
  3. Развиваться по управленческой лестнице, проектной (Project manager -> Program Manager -> CTO) или бизнес (Product manager).

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

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

Профессия бизнес-аналитик

Бизнес-аналитик (Business Analyst) — специалист, задачей которого является детальное изучение структуры компании, выявление проблем и поиск путей их успешного разрешения.

Профессия бизнес-аналитика высокооплачиваема, престижна и перспективна.

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

История профессии

Необходимость в оптимизации и автоматизации бизнес-процессов возникла около двадцати лет назад в Западной Европе и США.

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

В должностные обязанности бизнес-аналитика входит:

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

Наиболее частые требования к бизнес-аналитику следующие:

  1. высшее образование (предпочтительно в сфере финансов, экономики, бухгалтерии);
  2. опыт работы с CRM, системами аналитической обработки данных или банковскими информационными системами;
  3. опыт работы в бизнес-аналитике;
  4. опыт написания ТЗ;
  5. опыт разработки регламентирующей документации;
  6. знание ПК;
  7. аналитическое мышление и умение систематизировать информацию;
  8. грамотная устная и письменная речь.

Как стать бизнес-аналитиком

Претендовать на должность бизнес-аналитика (Business Analyst) могут выпускники экономических, финансовых, технических или математических факультетов, владеющие теоретическими знаниями в области анализа и моделирования бизнес-процессов.

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

Заработная плата бизнес-аналитика зависит уровня профессиональных навыков и стажа работы специалиста.

На сегодняшний день она колеблется в пределах 45-150 тысяч рублей в месяц. Средняя зарплата бизнес-аналитика находится в районе 80 тысяч рублей в месяц.

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

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

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

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

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

Специфика профессии

  • это хорошо оплачиваемый труд;
  • творческая работа каждый проект уникален и требует своего подхода к разработке;
  • видна ощутимая польза деятельности, когда рабочий процесс в фирме имеет четкий стиль и последовательность;
  • приобретение навыков коммуникативного общения, а также расширение круга полезных знакомств за счет проектов в разных организациях.
  1. работа системного аналитика не всегда ограничивается рамками одного города, а потому людям этой профессии много времени приходится проводить в командировках;
  2. клиент не всегда в состоянии понять отличие одной системы от другой, отсюда разногласия, споры, непонимание;
  3. высокий рабочий ритм;
  4. нередко пользователи негативно относятся к внедрению новой информационной системы;
  5. часто заказчик не может сформулировать задачу.

Место работы — в крупных компаниях: банки, финансовые корпорации, топливно-энергетические комплексы и пр. В компаниях-интеграторах, на предприятиях, где существуют отделы системного анализа.

Личные качества

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

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

Карьера — в крупных компаниях: банки, финансовые корпорации, топливно-энергетические комплексы и пр. В компаниях-интеграторах, на предприятиях, где существуют отделы системного анализа.

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

И еще один нюанс. Сразу после института стать системным аналитиком сложно. Хотя вакансий встречается много, везде требуются профессионалы с опытом. В этом случае можно начинать карьеру с должности помощника аналитика стажера.

Курс молодого БА

В последнее время профессия аналитика в сфере разработки программного обеспечения (в дальнейшем будем писать ПО, дабы аббревиатура не вызывала у вас недоумения, когда вы наткнётесь на неё на специализированных сайтах) стремительно набирает популярность среди представителей не только IT-сферы, но и «неайтишных» специальностей.

Студенты, молодые специалисты, работники со стажем – многие проявляют страстный интерес к загадочному и интригующему словосочетанию «бизнес-аналитик».

Наиболее простое и близкое к ИТ определение: аналитик – это промежуточное звено между заказчиком программного продукта (а также будущими его пользователями) и его разработчиками.

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

Какова вероятность того, что, объясняя им суть ваших пожеланий, вы не потратите себе нервы, стараясь донести до них мысль, что то, что они делают, не есть «красиво и удобно»?

А как вы отреагируете на их заявления типа «вам конвектор в полу нужен»? Несомненно, вы, в конце концов, найдете с ними общий язык.

Но теперь представьте, что в индустрии разработки ПО специализированный сленг/понятия/принципы построения систем в разы сложнее и объемнее, а программисты зачастую проявляют гораздо больше нежелания вас понимать и общаться с вами обыденным человеческим языком (извиняйте, читающие нас программисты; вы не все такие.

Вот тут-то и приходит на помощь этот самый аналитик. Международный Институт Бизнес-Анализа (IIBA, International Institute of Business Analysis) определяет бизнес-аналитика как профессионала, который «понимает проблемы и возможности бизнеса в контексте требований и рекомендует решения, позволяющие организации достичь своих целей.

Наиболее часто встречающиеся разновидности IT-аналитиков это:

  • Бизнес-аналитик
  • Системный аналитик
  • Аналитик требований

Бизнес-аналитик (Business Analyst, BA) – как правило, это специалист, занимающийся изучением и моделированием конкретной предметной области.

Другими словами, он должен выяснить пожелания заказчика, проанализировать их, дополнить при необходимости, оформить определённым образом (построить модели, задокументировать хотя бы общие пожелания клиента) и передать команде разработки.

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

Системный аналитик (System Analyst, SA) – аналитик, значительно более приближенный к команде разработки, чем БА; специалист, который должен транслировать команде высокоуровневые требования к ПО, полученные от бизнес-аналитика, в виде детальных функциональных требований к системе, естественно, на языке команды разработчиков.

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

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

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

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

Большинство аналитиков в любой аутсорсинговой компании в нашей стране (то бишь, компании, занимающейся разработкой ПО под заказ) – это именно аналитики требований.

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

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

Что же касается системных аналитиков, то без наличия BA в штате они имеют мало смысла, за исключением случаев, когда попадается заказчик с бизнес-аналитиками со своей стороны или же заказчик-профессионал, знающий и умеющий донести до команды свои «хотелки» (да-да, далеко не все заказчики точно знают, чего хотят).

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

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

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

Коммуникабельность и коммуникативность, а именно:

  1. умение слушать и слышать.
  2. умение выражать свои мысли четко и ясно.
  3. умение устанавливать и налаживать контакты и связи с другими людьми.

Знание IT и основ разработки ПО (так называемый, технический бэкграунд).

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

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

Креативность. Мы не зря отметили, что это качества идеального аналитика.

Скажем больше: по мере продвижения по карьерной лестнице (а об этом мы еще будем писать), вам придется развить и приобрести дополнительные навыки, не менее сложные и интересные.

Не нужно забывать о том, что у каждой профессии есть как достоинства, так и недостатки.

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

Почему вам может понравиться работа бизнес-аналитика:

  • это интересно (конечно не всегда, конечно в зависимости от компании и проекта, но всё же…)
  • работа связана с постоянным общением (в отличие от разработчиков и тестировщиков у аналитика не получится весь день сидеть перед монитором, и это, на наш взгляд, прекрасно)
  • разнообразие видов деятельности (здесь вам и общение, и анализ информации, и документирование, и дизайн, и решение проблем, и управление командой, и проведение лекций – и это еще не все)
  • возможности роста вширь и вверх (при наличии желания, естественно)
  • материальная сторона вопроса
  • возможность посетить другие страны и все вытекающие отсюда плюшки.
Другие публикации:  Оформить визу в польшу в львове

Почему вам может не понравиться работа бизнес-аналитика:

  1. это скучно (опять-таки, зависит от специфики проекта и компании – иногда вам придется заниматься однообразной и рутинной работой, либо работой, которая вам не по душе)
  2. необходимость общаться (точнее, вам волей-неволей придётся общаться, причем, в большинстве случаев, не только на русском, плюс периодически делать публичные выступления)
  3. необходимость переключаться между различными видами деятельности и, по мере прогресса, между несколькими абсолютно разными по своей природе проектами
  4. необходимость принятия решений и несения ответственности за свои решения.

Здесь всё сугубо индивидуально, плюс очень многое зависит от того, где вы будете работать (в какой компании/с какими заказчиками/с какой командой/на каком проекте/в какой предметной области).

Карьера Бизнес-аналитика

Бизнес-аналитик — профессия относительно новая для современного рынка труда.

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

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

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

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

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

Задачи бизнес-аналитика

Модель компетенций младшего бизнес-аналитика

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

Дифференцирующие компетенции: работа в команде, ответственность, ориентация на качество.

Карьерный путь

Заработная плата

Заработная плата бизнес-аналитика варьируется от 500 до 3500 USD в месяц в зависимости от опыта работы и места работы.

Оплата труда младшего бизнес-аналитика без опыта работы варьируется от 500 до 600 USD в месяц.

Чем занимается бизнес-аналитик?

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

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

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

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

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

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

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

Этот процесс называется «реинжиниринг», или бизнес-инжиниринг (выделен в отдельную отрасль ведения бизнеса недавно — в конце прошлого столетия). По сути, это есть процесс избавления от неработающих механизмов и внедрение новых.

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

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

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

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

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

Бизнес-аналитик «широкого профиля» обычно имеет в списке своих должностных обязанностей такие пункты, как автоматизация процессов учета, сбыта и хранения товарных позиций.

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

Так снижаются риски и возможные затраты. Широкопрофильные аналитики должны заниматься составлением стратегии в целом для всей компании.

Чем занимается бизнес-аналитик?

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

Что должен уметь БА?

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

Также бизнес-аналитик должен обладать специальными знаниями, к примеру, в области проектирования на специальном языке моделирования (UML).

То есть среди навыков специалиста приветствуется не просто умение предоставлять отчет в виде цифр, таблиц и схем в PowerPoint, а детально прорабатывать модели ведения бизнеса. Последнее осуществляется в следующих программах: BPWin, RRose, ARIS и других.

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

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

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

Что должен знать бизнес-аналитик

Аналитик широкого профиля занимается:

  1. сбором и систематизацией результатов анализа;
  2. созданием моделей бизнес-процессов;
  3. анализом эффективности и составлением предложений по оптимизации работы;
  4. разработкой регламентов, документации, системы отчетности;
  5. сравнительным анализом с конкурентами деятельности организации;
  6. составлением презентаций для руководителей или заказчиков.

Заработная плата

Данная профессия относится к высокооплачиваемым и считается очень престижной. Бизнес-аналитики являются специалистами уровня директоров. Где работают бизнес-аналитики и получают достойную плату?

Перспективна профессия в банковском и торговом секторах, строительной сфере. А наиболее прибыльна в добывающей промышленности и ИТ-секторе.

Зарплата аналитика зависит от его профессиональных навыков и опыта. На сегодня уровень зарплат, в зависимости от региона России, колеблется от 40 до 140 тысяч рублей в месяц.

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

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

Так, в Школе ИТ-менеджмента в Академии народного хозяйства при Правительстве РФ предлагается программа для менеджеров проектов и бизнес-анализа.

Претендентов на должность финансовый аналитик выпускает Российская экономическая академия имени Плеханова. В МФТИ предлагается программа для студентов, желающих получить специальность системного аналитика.

Факультет бизнес-информатики ГУ ВШЭ тоже подготавливает бизнес-аналитиков, но только в сфере информационных технологий.

И конкретно направлению аналитики посвящена программа Высшей школы экономики в Москве.

Будущему аналитику следует развивать в себе тренерские и рекрутинговые навыки.

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

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

Следует выбрать специальности для экзаменов — продвинутый уровень: финансовый менеджмент и управление эффективностью.

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

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

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

При этом они должны быть компетентны не только в области IT (что является уже шаблоном по отношению к профессии бизнес-аналитика), но и в целом в ведении бизнеса.

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

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

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

Кто такие бизнес-аналитики 1С?

Что же представляет собою деятельность такого профессионала как бизнес-аналитик 1С? Часто бизнес-анализ описывают как серьезное событие, указывает которое на необходимые бизнес потребности.

Бизнес аналитик 1С что же это за человек, если о нём говорить с точки зрения его многофункциональных обязательств?

Вот ряд главных критериев, какими, как мы предполагаем, обязан преобладать этот специалист:

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

Бизнес-аналитик 1С специализируется в установленных областях коммерции и индустрии. К примеру, некоторые из бизнес аналитиков 1С могут действовать только лишь в строй сфере, прочие с ИТ-структурами и т.д.

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

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

Бизнес-аналитик 1С обязан по работе контактировать с разными людьми (как внутри фирмы, так и за пределами её), это весьма немаловажно с целью установления в окончательном итоге их производительности в едином деле.

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

С целью аналитики в сфере коммерции в настоящее время имеется много альтернатив и направлений деятельности. В том числе, все основные менеджеры основной массы фирм считаются превосходными специалистами в сфере аналитики.

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

Несомненная несостоятельность подобного подхода, станет всё чётче и острее выражаться совместно с формированием интеграционных действий.

Роль и обязанности бизнес аналитика в организации

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

Обязанности бизнес аналитика концептуально определены международным стандартом BABOK (свод знаний по бизнес-анализу и управлению требованиями), но в переводе на русский язык этот стандарт до настоящего времени не опубликован.

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

  • бизнес аналитик может иметь компетенции в информационной системе(системах) организации, но не обладать навыками и компетенциями в совершенствовании и реинжиниринге бизнес процессов
  • и наоборот, бизнес аналитик может обладать навыками совершенствования и реинжиниринга бизнес процессов, но не быть информационным бизнес аналитиком, обладающим обширными знаниями информационных систем
  • одна из причин этой градации в знании, использовании бизнес аналитиком и организацией в которой он трудоустроен систем управления бизнес процессами
  • предпочтения бизнес аналитика могут не совпадать с ранее выбранной и придерживаемой политики ИТ стратегии развития организации
  • кроме того, на рынке представлены инструменты BPMS и BI, которые необходимо интегрировать в информационные системы организации, а это достаточно трудозатратные проекты, требующие кропотливого описания модели организации «как есть» и как будет»
  • затем бизнес аналитику предстоит доказать менеджменту организации преимущества реализации такого проекта, затем при одобрении следуют этапы автоматизации
  • по окончании проекта, если это окончание будет достигнуто, будет сформирована «жесткая модель» интеграции информационных систем со сбором аналитической информации
  • затем следует первое и последующее изменение внутренней среды организации и воздействие внешних факторов и эта модель становится устаревшей и подлежит корректировке путем повторной автоматизации

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

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

Компетенции информационных бизнес аналитиков в основном дают в России несколько компаний интеграторов и несколько ВУЗов в стране.

Стоит отметить, что BABOK предлагает и классифицирует таких аналитиков несколько иначе.

В основном компетенции бизнес аналитика по повышению эффективности путем оптимизации бизнес процессов всех уровней управления появляются у специалистов, получивших практические навыки в проектах по построению систем управления с применением принципов BPM.

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

Специфика трудоустройства и работы в отечественных и иностранных компаниях

Компаниями востребованы бизнес аналитики, имеющие навыки работы с информационными системами работодателей, при этом у работодателя в большинстве случаев, стремящихся к 100%, отсутствует созданная и доступная методология и средства автоматизации для САМОДИАГНОСТИКИ своих организаций и последующего построения системы управления компанией с исполняемыми бизнес процессами.

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

Карьерные и профессиональные перспективы

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

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

Роль бизнес аналитика на рынке изменит свое положение в оргструктуре организаций. Таких людей надо подготавливать (как специалистов) через образовательные программы в ВУЗах.

Leave a Reply

Ваш e-mail не будет опубликован. Обязательные поля помечены *