Ключевые качества бизнес-аналитика в ИТ

в 16:32, , рубрики: ECM/СЭД, бизнес-анализ, бизнес-процессы, интеграция, сэд, управление проектами

Доброго времени суток.

Изложить свои мысли о теме настоящей публикации натолкнула вполне насущная, «жизненная» необходимость — постепенно приближается время, когда возникнет потребность искать/нанимать на открытом рынке бизнес-аналитиков в штат компании (бизнес в области автоматизации процессов управления документами, контроля исполнительской дисциплины и т.д., в «простонародье» — СЭД). Все специалисты этого профиля, опыт и компетенции которых известны, иными словами тех кого знал и кого видел полезным для компании, либо уже в команде, либо устроены тоже неплохо. Проблему осложняет тот факт, что сколько ни старался, не получается сформулировать кратко и адекватно компетенции, особенности, которыми данный субъект должен обладать. Какие личные качества и таланты должен проявлять — что тоже актуально, так как морально подготовился к тому, чтобы искать талантливых новичков и пытаться их «выращивать». Уверен, что размышления ниже по тексту будут полезны менеджерам проектов, собственникам небольших ИТ-компаний интеграторского типа, да и самим бизнес-аналитикам.

Термины и определения

Сначала вопрос самого термина «бизнес-аналитик» (далее БА). Потеряв надежду подобрать универсального определение этому термину (Яндекс и Google подсказали, что в этом я не одинок) и чтобы не вдаваться в дискуссию о методологиях, классификациях и ГОСТах, для целей публикации определю очень по-простому: бизнес-аналитик — этот «тот самый парень» (или девушка), который общается с представителями Заказчика ИТ-проекта (внедрения бизнес-приложения в частности), выявляя, формализуя и документируя бизнес-требования таким магическим образом, что это с одной стороны поймет и согласует заказчик, а с другой стороны не вызывает инфаркта у остального производства (архитектора проекта и программистов, тестеров, поддержки, тренеров и т.п.).

Работа БА во внутреннем ИТ-подразделении

Мое понимание качеств и особенностей Бизнес-аналитика развивалось в течении 7 лет. С нуля, начиная после вуза карьеру во внутреннем ИТ-подразделении крупной торговой компании именно с позиции бизнес-аналитика, начало складываться мнение, что БА — просто некая прослойка, переводчик между бизнес-терминами и терминами разработчиков. Ну и круто, конечно, научится использовать Rational или BPVA (в крайнем случае MS Visio), стать «немного дизайнером», чтобы рисовать эффектные схемы, которые наглядно демонстрируют «as-is» и «to-be». Важно отметить, что особенностью БА во внутреннем ИТ — отсутствие острой необходимости в специализации в какой-то области (если ты не в Газпроме работаешь), имею виду класс систем и процессов: не было особой разницы — внедрять/развивать ERP, ECM — пожалуйста; переключится на CRM — без проблем. Думаю, что причина банальна — внутри бизнеса (за исключением возможно мега-корпораций, и сложного производства) знания о практически всех процессах и их понимание возникает по факту самого постоянного присутствия в компании. Поэтому на тот момент был согласен с мнением и всем, кому мог, постулировал, что для БА не важно, что внедрять, не важно, на чем внедрять.

Бизнес-аналитик в системном интеграторе

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

Становится действительно важным, в том числе для самого БА, такой параметр проекта, как «сроки» (если в интеграторе позаботились о более менее адекватной системе мотивации персонала). Естественно, что в данной парадигме, мнение об отсутствии необходимости специализации для бизнес-аналитика (в отрасли и/или классе систем) становится полностью несостоятельным: быстро начать ориентироваться в новом проекте с жесткими сроками без значительного опыта и знаний в предмете автоматизируемых бизнес процессов, а также в архитектуре и особенностях платформы (обобщая, используемых средств для автоматизации) практически невозможно, конечно с оговоркой, если качество проекта в целом, и твоей работы в частности, тебя волнует. Необходимость участия одного БА одновременно в нескольких проектах (3-5 зачастую) — еще один аргумент в пользу специализации.

Взгляд с позиции руководителя проекта

Через 1,5 года, заняв позицию РП в той же компании, на проблематику удалось взглянуть со стороны. Имея в подчинении 3 разных бизнес-аналитиков, стало очевидным, без преувеличения, колоссальное влияния компетенций бизнес-аналитика на все параметры проекты:

  • Функциональные границы проекта — без комментариев.
  • Рабочая атмосфера. Как показывает практика, обычно проектная команда, пусть и не в открытую, считает главным виновником всех проблем почему-то именно бизнес-аналитика (ну если не считать РП естественно). Умение не допускать больших «погрешностей», а главное умение достойно выйти из напряженной ситуации взаимных претензий внутри команды, сглаживать конфликты во многом позволяет БА существенно повысить мотивацию всей группы.
  • Сроки проекта. Зачастую этап, назовем его «анализ» (обследование, проектирование), существенная часть проекта по длительности, в среднем 10-30%, который зачастую нельзя поставить параллельно с другими работами по этому проекту, даже при большом желании. Соблюдение срока этого этапа, прямо влияющего на срок всего проекта, почти полностью зависит от организованности и компетенций БА (или ведущего БА или РП, если в одном проекте их несколько).
  • Решение организационных проблем путем облегчения коммуникаций. Как правило, бизнес-аналитик лучше, чем кто-либо еще знаком и пользуется доверием большинства сотрудников у заказчика. Организовать оперативно взаимодействие с сотрудниками клиента, не дожидаясь формальной эскалации — через него гораздо проще.
  • Незаменимый ресурс в ходе проекта. Думаю, что смена руководителя проекта в ходе проекта среди топ-5 основных причин появления некачественных проектов в этой сфере (за исключением наверное совсем уж типовых проектов). Смена бизнес-аналитика в ходе проекта — вероятно на соседней строчке такого рейтинга. На аргумент о необходимости качественного документирования, ответил бы так: к сожалению все не задокументируешь. В проекте помимо понятных вещей, в виде функциональных требований, целей, описания задач, очень часто важны атмосфера, эмоции, «тайные» ожидания заказчика. Формализовать и перенести это на бумагу в принципе далеко не всегда возможно.
  • Приемка проекта и его бюджет. Обычно в практике внедрения на рынке компания-заказчик по выручке и другим показателям в десятки, сотни раз крупнее компании-внедренца. Слон и Моська так сказать. Зачастую «Слон» считает вполне приемлемым опираться в таких отношениях не только на задокументированные договоренности, но и на кулуарные разговоры, обещания «фишечек», «плюшечек», которые когда-то по его мнению звучали, но почему в документацию не попали. Аргументация вида, что «Вы же профессионалы, должны были это учесть, мы естественно могли что-то пропустить, согласовывая сотни страниц документации, но это Вы же мне лично обещали» вполне состоятельная, как минимум потому, что он — «Слон», а Вы — «Моська», а проект сдавать как-то надо. Недопущения таких ситуаций, вероятно это часть так называемого управления требованиями и ожиданиям, и — одна из главнейших задач БА совместно с РП. Самое печальное, что этому, на мой взгляд, в принципе невозможно научить, это своего рода искусство и талант, ну и естественно опыт.

Взгляд с позиции работодателя

1,5 года ведения проектов в качестве РП и подработки в качестве продавца ИТ-услуг подтолкнули к совершенно неожиданной и странной идее отрыть совместно с коллегами собственный бизнес. Поработав какое-то время в трех ролях «Продавец»-«РП»-«БА» на нескольких проектах (кстати очень эффективная, правда не масштабируемая бизнес-модель), появились бизнес-аналитики в собственном штате. Помимо оценки как РП, с точки зрения владельца бизнеса, удалось заметить еще очень важные полезные качества БА, из-за которых я искренне считаю профессионального (в моем понимании) бизнес-аналитика ресурсом, во многом определяющим успешность бизнеса по внедрению бизнес-приложений:

  • Стратегическое управление требованиями. В какой-то момент мы начали придерживаться парадигмы, в которой стараемся стандартизовать любыми способами все наши проекты на уровне архитектуры самого решения. Причина тривиальна — сопровождение и развитие архитектурно схожих проектов (естественно функционально они могут очень сильно отличаться) намного проще. Вплоть до того, что сознательно убеждаем заказчика в необходимости придерживаться определенных «архитектурных принципов», даже в ущерб величины бюджета будущего проекта (на рынке зачастую другой подход: «все, что угодно за ваши деньги» вдаваясь, порой в ненужную и сильную кастумизацию под требования заказчика, зачастую не сильно эффективные. Да-да, принцип Парето и тому подобное. Излишняя кастумизация платформ имеет существенный плюс — можно объяснить и получить намного больший бюджет, и существенный минус — сложность сопровождения и развития). Роль БА в таком стратегическом подходе, на самом деле ключевая — только мега профессиональный бизнес-аналитик способен формализовать требования таким образом, чтобы их реализация не требовала существенного «допила», при этом убедив заказчика, что формализованное таким образом требование — идея самого Заказчика.
  • Кросс-продажи и развитие решения. Качественный бизнес-аналитик — это тот, кто никогда не пропустит, не забудет коротких фраз, веяний, впитанных в процессе своего взаимодействия с сотрудниками заказчика, которые можно «раскрутить», докопаться и сформулировать новую потребность. Имея на руках признаки реальной потребности, замеченной именно в реальной работе сотрудников той или иной компании, продать проект по «закрытию» такой потребности, на фоне успешного первого проекта — до нелепости просто (макроэкономику в расчет не берем, считаем что деньги у всех более менее имеются)

Заключение

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

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

Спасибо за внимание!

Автор: GavrilovAS

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js