Примерно так я думал лет 5 назад, когда после биологического вуза, армии и пары дерьмовых работ захотелось чего-то интересного и полезного для бюджета.
Благодаря какому-то неебическому чуду и непрошибаемой уверенности что это все легко и я таки устроился бизнес-аналитиком. И примерно еще месяца 4 беспощадно тупил и дергал всех и вся с кучей вопросов.
А теперь мои друзья (да, у меня есть целых 3 человека, которые со мной общаются!), стали меня спрашивать: а как так? Что нужно сделать, чтобы попасть в бизнес-анализ? И когда я начинаю сбивчиво рассказывать о нотациях процессов, пользовательском пути или еще о чем-то более эфемерном их лица выглядят примерно так:
Поэтому пилю пост, может быть вам тоже будет интересно. Если зайдет - продолжу, если нет - ну да и хер с ним! Пост будет в формате: немного личного опыта/статистики и куча полезных ссылок для самостоятельного изучения. Разжевать всю суть профессии - не хватит и 20 постов, но я постараюсь хотя бы задать вектор.
Ладно, со вступлением покончили. А начну я как и всякий уважающий себя аналитик - со статистики. Берем первые 100 попавшихся под руку вакансий на hh.ru. Отсеиваем совсем бредовые, специфической отрасли (вроде аналитики в due diligence) и позиции уровня senjor с опытом работы от 5 лет и ЗП от 200к (там почти везде нужно много технических знаний).
Что получаем:
Методика простая: вижу требование или обязанность - ставлю 1 балл. 100 баллов - 100%.
Выборка нифига не репрезентативная, через неделю цифры могут быть другими, но получить представление об общей картине по данной вакансии она позволяет. Еще один момент: работодатели могут писать одно, а подразумевать еще 2-3 пункта сверху, которые "ну само собой". Например, "аналитический склад ума".
Из этой выборки мы можем в целом понять, что это за зверь такой - бизнес-аналитик и что он делает на работе. Вообще вот тут все неплохо написано (но на требования лучше смотреть в табличку или на hh).
Для тех, кому лень переходить по ссылке, украду оттуда пару фраз для понимания:
Говоря простым языком, нам нужно что-то поменять в компании, а бизнес-аналитик помогает определить потребности и выработать решения, чтобы это изменение воплотить в жизнь.
Всех аналитиков в ИТ можно поделить на 2 части:
Ближе к бизнесу — те, кто описывают, оптимизируют и разбираются в бизнес-процессах и их изменениях.
Ближе к разработке — те, кто глубоко понимают устройство программы, архитектуру и как программа работает изнутри.
И да, системным аналитикам платят больше. Но и порог входа туда - выше. Если вы идете в бизнес-анализ совсем не из ИТ, я предлагаю начинать с левого угла и постепенно двигаться в сторону понимания систем. ИМХО, мне так было проще=)
Вставлю небольшую ремарку
Мы сейчас говорим о бизнес-аналитике в ИТ-сфере. Есть еще не менее популярная и оплачиваемая область консалтинга, где у бизнес-аналитика немного другие задачи и требования. Если будет интересно, распишу отдельным постом, т.к. в консалтинге я тоже успел поработать.
Теперь предлагаю пройтись по требованиям к нему и по тому, как этим требованиям соответствовать. Начнем с самого частого требования:
1. Знание нотаций бизнес-процессов, правил моделирования и их описания.
Что такое нотации: это универсальный язык описания любого процесса на предприятии. Да и не только на предприятии, вообще любого процесса.
Например, процесс мытья своего МПХ можно описать в нотации EPC примерно так:
Три основные нотации, которые сейчас используются на рынке: BPMN 2.0, EPC и UML. UML уже ближе к системному анализу, EPC - к бизнесу. BPMN где-то в средине. Новичку я предлагаю освоить BPMN 2.0 и EPC, а потом добирать недостающие в процессе работы. Также еще встречаются IDEF0, VAD - можно ознакомится поверхностно, к тому же сама по себе VAD очень простая, а IDEF0 сейчас не так часто используют (хотя лучше ее знать для собеседования, могут спросить).
Где можно научиться?
Статья для начала и общего понимания, что такое бизнес-процесс от Элмы. Я рекомендую посмотреть еще 3 лекцию от открытого образования, она немного нудная зато более подробнее раскрывает тему.
Для тех кто любит долгое чтиво, вот книжка. ИМХО, моделировать вы после нее не научитесь, но зато она очень неплохо дает общее понимание бизнес-процессов и проблем. Для ИТ немного устаревшая информация, поэтому можно читать только если все остальное уже прочли.
Про нотации на Открытом образовании, лекции 4, 5. В самом курсе очень много теории, большая часть которой совсем не понятна для человека без специализированного образования. Если есть силы и желание - можно пройти весь курс. Для нотаций лучше посмотреть видео в лекции 4: событийная цепочка процессов и лекцию про типичные ошибки. Остальное - расскажу в пункте про ARIS. Лекцию 5 можно глянуть целиком.
Статья бизнес-студио - EPC. Тут важно помнить, что базис они раскрывают, но у работодателя может быть подобраны элементы нотации под себя и настроены другие правила взаимодействия, особенно если компания работает с профессиональным ПО. Поэтому тут упор в обучении на основные элементы. Связи между ними можно просмотреть, они типовые, но могут меняться.
Cтатья ELMA - BPMN 2.0 У бизнес-студио по BPMN очень мутная статья, эта лучше. На хабре тоже
в целом понятно рассказывают. Для тех, кто любит слушать нудных ребят (но говорит в целом по существу)
вот видео
Сложный, но всеобьемлющий документ про IDEF0 и примеры. Вот тут попроще, но ряд нюансов упущен. Сразу скажу, что IDEF0 это обычно обобщенное моделирование либо всех процессов организации в одной модели либо какого-то крупного блока. Поэтому не сильно популярно в ИТ, где обычно автоматизируют не все процессы сразу, а какую-то часть, которую нужно расписать детально.
Простой статьи про правила выделения бизнес-процессов в компании не нашел, есть немного сложная.
Для первого приближения к нотациям и описанию БП, наверное все. К сожалению очень мало годных статей: они либо простые и бестолковые либо сложные и явно не для новичков. Поэтому, господа, товарищи коллеги и прочие причастные к бизнес-анализу предлагаю накидать в комменты источники. Все что выше - мое ИМХО по данной профессии, поэтому конструктивная критика приветствуется!
Если зайдет, продолжу разбирать эту тему.
