Тема бизнес-анализа мне очень близка. Я уже очень много лет работаю в ИТ-проектах, начинал с работы программистом, потом пошел в бизнес-анализ, после чего несколько лет работал руководителем проектов.
Кроме того, я глубоко занимался вопросами методологии бизнес-анализа, в том числе, изучал опыт различных не-1С-ных продуктов, таких, как Галактика, Парус, SAP – изучал их проектную документацию, смотрел подходы. Конечно, у меня был доступ далеко не ко всем их методическим материалам по этим продуктам, а лишь к той части, к которой удавалось получить этот доступ.
Но мне было интересно, и у меня в жизни был такой этап, когда мне самому приходилось разрабатывать методологии проектного управления, включающие и бизнес-анализ.
Мы рассмотрим три вопроса:
-
подводные камни профессии;
-
за что отвечает бизнес-аналитик;
-
какими качествами он должен обладать.
Подводные камни профессии
Профессия аналитика имеет ряд «подводных камней»:
-
Неопределенность к функциональности самого аналитика.
-
Высокий уровень ответственности.
-
Риск выгорания в профессии аналитика.
-
«Не всем дано» – не каждый, кто хочет стать бизнес-аналитиком, может им стать.
Начнем с неопределенности. Есть неопределенность к функциональности аналитика – непосредственно к его функциям, что он должен делать. И, отсюда следует неопределенность даже к названию профессии.
Предполагается, что лучше всего функции, которые должен выполнять бизнес-аналитик, знает сам бизнес – к примеру это может быть завод или ИТ-компания, которая занимается внедрением.
Если компании нужны функции бизнес-аналитика, она начинает его искать на рынке. Но, простой анализ того, специалиста с какими функциями ищут работодатели, вызывает много вопросов.
Все эти тезисы взяты с HeadHunter – здесь перечислены функции, которыми должен обладать человек, которого ищут.
Специалист должен и консультировать пользователей, и проводить обучение, и заниматься тестированием. Конечно же, он должен уметь проводить демонстрацию по любым программным продуктам, знать все методологии всех видов учета, понимать архитектуру внедряемых систем, знать СКД и уметь строить отчеты, писать документацию, обязательно проектировать доработки и ставить задачи программистам, все это контролировать и т.д., и т.п.
Вот такой мульти-человек, который все умеет – и все это называется «бизнес-аналитиком».
Но бизнес – он же умный и понимает, что нет таких людей, которые будут все это одновременно делать, причем на одном и том же уровне. Поэтому бизнес берет только те функции, которые ему требуются сейчас, компонует их и придумывает им название.
В итоге у нас появились аналитики, консультанты, системные архитекторы, просто архитекторы, миксы между программистами и консультантами, и даже некие универсальные внедренцы. Кого только нет…
Все перечисленные на слайде названия профессий тоже взяты с HeadHunter.
Эта ситуация ненормальная, так быть не должно – но она сформировалась под влиянием специфики, которая есть в 1С-среде по поводу бизнес-анализа.
Сложнее всего – молодым специалистам, которые приходят в индустрию. Когда человек приходит с института в компанию 1С- франчайзи на должность некоего 1С-аналитика – он реально не понимает, чего от него хотят. В институте его бизнес-анализу не учили, а чему он должен научиться сам, ему тоже не очень понятно. Даже если он спросит у опытных 1С-ников, ему никто не сможет внятно объяснить, где учиться и чему учиться, чтобы стать бизнес-аналитиком в 1С.
Все это вызывает определенные проблемы. И я постараюсь рассказать свое видение.
Почему такая каша в наборе функциональности и в наборе должностей?
Дело в том, что до сих пор продолжается попытка разделения бизнес-анализа и системного анализа. Но, я считаю, что в нашей индустрии 1С бесполезно пытаться делить бизнес-анализ и системный анализ. В классической веб-разработке или у крупных интеграторов при разработке больших систем такое разделение принято и там оно уместно. Но у нас в 1С так делить нельзя.
И сейчас я постараюсь аргументировать, почему ситуация в 1С именно такая, и почему этот замкнутый круг образуется.
Уже больше 20 лет на рынке существуют проекты на платформе 1С, и за это время ни у кого ни разу это разделение построить не получилось.
Хотя попыток предпринималось очень много, в том числе крупными компаниями и даже самой фирмой «1С» – на заре 2000-х годов она пыталась ввести это разделение, но потом забросила. Никто не знает, почему.
Почему это гиблая затея?
-
Потому что классический бизнес-анализ – это консалтинг, бизнес-консультирование, но не автоматизация. Представьте, директор некого заказчика говорит аналитику 1С: «У нас есть 20 видов выпускаемой продукции. Мы думаем 2 из них перестать производить, а у одного – снизить себестоимость на 10%. Скажите, что будет с бизнесом?». Какой ответ даст типичный специалист 1С? Он скажет: «А я откуда знаю? Это же ваш бизнес! Вы подумайте, потом скажите, что хотите сделать, и мы вам это автоматизируем». А бизнес-анализ – это изучение того, как работает бизнес, экономика, анализ больших объемов данных, причинно-следственных связей, и он совсем не про автоматизацию. Эта классическая модель к 1С вообще не применима.
-
Есть и другой аргумент: 1С – это, в первую очередь, учетная система, которая требует экономических и смежных знаний всей команды. Возьмем, к примеру, разработку. В конфигурации есть объект метаданных «План счетов», и даже в документации у программиста присутствуют такие термины как «Дебет» или «Кредит», деление на активные и пассивные счета. Все это нужно не только знать, но и понимать. Поэтому, вся команда внедрения на проекте 1С должна в разной степени обладать некой терминологией, которую диктует учетная система.
-
Помимо этого, в 1С отсутствует в чистом виде процесс проектирования базы данных. Если брать систему не на 1С, то сначала нужно спроектировать базу данных, нарисовать все таблицы, реляционные связи, проверить на нормализацию и т.д. Это довольно сложный процесс, отдельный предмет, который изучают в институте. Многие 1С-ники вообще не знают, что такое нормализация и даже не думают о ней. Все это скрыто за средой конфигуратора, здесь ведутся операции с предметно-ориентированными метаданными, и процесс заметно упрощается. Потому, необходимость в системном аналитике в явно выделенном виде снижается.
-
Точно так же с задачами по интеграции – это вроде бы тоже задачи отдельного системного аналитика, но у нас подавляющее большинство проектов настолько жестко завязаны на технологии, которые уже вшиты в платформу (Веб-сервисы, HTTP-запросы и т.д.), что люди очень редко выходят за эти границы.
-
Опять же разработка «с нуля» ведется крайне редко – в 98% случаев за основу берутся существующие конфигурации. Потребности в глубоком системном анализе снижаются, и большую часть функций берут на себя люди, которые либо знают систему, либо знают бизнес-процессы, учетные методологии.
-
Последний момент – это анализ экзаменационных билетов 1С на специалиста по разработке. Возьмите любой билет и обнаружите, что текст задачи формулируется в виде бизнес-задачи. Она может быть как-то связана с экономическими понятиями, но там нет требования: «Добавьте в регистр такое-то измерение и измените модуль проведения». К этому разработчик должен прийти, но формулируется задача в совершенно другом стиле. Т.е. вендор предполагает, что специалисты, которые занимаются разработкой, владеют бизнес-терминологией, знают какие-то предметные области, знают учет, в том числе бухгалтерский.
Это странная ситуация. И у меня, как бизнес-аналитика, есть предположение, что где-то в высших эшелонах управления самой фирмы «1С» витает такое мнение, что консультанты и бизнес-аналитики 1С – это некая полуискусственная придуманная работа, а делать все должны разработчики. Иначе непонятно, почему за 20 лет от самого вендора до сих пор нет никаких методологических рекомендаций по взращиванию бизнес-аналитиков, по навыкам, которыми они должны обладать.
В последние два года со стороны фирмы «1С» появились движения в этом направлении – возможно, что-то изменится.
Есть еще один интересный вопрос: «Были ли попытки систематизировать требования к квалификации?». Да, они были.
У нас есть государственные профессиональные стандарты – «Специалист по информационным системам» и «Бизнес-аналитик». Это не те стандарты, которые были когда-то, советские, это новые современные стандарты 2016-2018 гг.
Так вот, профстандарт бизнес-аналитика никакого отношения к тому, чем мы занимаемся, не имеет. Здесь чистой воды консалтинг, знание организационного управления и экономических дисциплин. Из требований к базовому образованию – именно экономика, менеджмент и смежные дисциплины.
Что касается стандарта для специалиста по информационным системам, то над ним работала группа компаний 1С-франчайзи (большой список участников) – они формулировали, что это за специалист. Почему так назвали – непонятно, никто не называет бизнес-аналитика как «Специалист по информационным системам», это какое-то искусственное название. Видимо, название «бизнес-аналитик» использовать не дали, а другие названия не подошли. Но это не важно, название ни о чем не говорит.
Однако, если проанализировать сам стандарт, посмотреть, чем должен заниматься этот человек, по мнению большого круга участников сети 1С-франчайзи, то получим следующую статистику упоминания терминов:
Мы видим, что упоминались слова:
-
190 раз – «бизнес-анализ»;
-
106 раз – «программирование»;
-
а дальше вся та каша, про которую я говорил – тестирование, обучение, архитектура, проектирование, учет и т.д.
Т.е. человек все это должен знать.
И возникает вопрос, за что же все-таки должен отвечать бизнес-аналитик IT/1С на проекте?
Я здесь специально выделил IT/1С, потому что хотелось бы, чтобы путаницы не возникало.
Т.е., если мы не хотим такого специалиста привязывать к 1С, тогда его нужно называть «бизнес-аналитик в ИТ». А если наоборот – то называть его «бизнес-аналитик 1С», чтобы было понятно, что этот бизнес-аналитик обладает навыками, которые требуются именно в индустрии автоматизации на платформе 1С, и не путать его с бизнес-аналитиками, которые занимаются чистой воды консалтингом. Иначе эта путаница будет вечной.
Так вот – за что должен отвечать бизнес-аналитик? Сейчас будет кульминационный слайд, на котором мы увидим ответ на вопрос – за что бизнес-аналитик отвечать должен, а за что он отвечать не должен.
Это та же самая картинка! Потому что действительно этот человек должен отвечать за все это вместе взятое.
Как же так? А самое главное – что с этим делать?
Давайте разберемся. Представьте себе нейрохирурга. Он не сразу стал нейрохирургом. Сначала он работал ассистентом хирурга и подавал инструменты. И только потом он начал сам оперировать.
Означает ли это, что нейрохирург не сможет больше ассистировать и подавать скальпель? Конечно, нет, просто он перестал это делать. Я веду к тому, что профессия – одна, но уровень компетенции разный.
Надо принять это как факт, что есть такая профессия, что она как-то называется. И пока окончательно название не «устаканилось», я предлагаю называть «бизнес-аналитик 1С» – это название более-менее прижилось, все его понимают.
У этой профессии должны быть определенные уровни квалификации, как например, в профессии программиста, где есть junior, middle, senior. Кстати, если посмотреть на некоторые западные и наши айтишные компании, у них для бизнес-аналитиков тоже встречается похожее разделение – нигде это не прописано, они так сами придумали, потому что понимают - есть такая профессия, и в ней есть определенные уровни знаний.
Я долго анализировал и пришел к выводу, что наиболее рациональное разделение – на четыре уровня квалификации. Условно я их назвал:
-
стажер;
-
младший аналитик;
-
старший аналитик;
-
эксперт.
Стажера можно было бы назвать нулевым, потому что он только принял решение прийти в профессию аналитика, но пока что сам ничего не умеет и не знает. Самостоятельно он работать не может – ему дают поручения, он их выполняет, результат оценивают.
Сейчас в нашей системе образования единственная специальность, где пытаются учить бизнес-аналитиков, – это «Бизнес-информатика». Но даже если поговорить со студентами, которые на ней учатся, они толком не понимают, кем будут работать.
Туда замиксовали разные полезные знания. Система образования уже вроде как понимает, чему нужно учить, но организованной системы нет. Поэтому, люди учатся на производстве.
Сначала они выступают в качестве стажеров, а потом постепенно понимают, какие навыки им надо приобретать для работы в конкретной компании.
Конечно, приход в профессию возникает не только снизу вверх или через обучение. Человек может прийти в профессию и сбоку. Например, в эту профессию приходят люди из программистов, из руководителей проектов, из бухгалтеров, экономистов, финансистов – они переквалифицируются и начинают заниматься автоматизацией.
Я покажу свое видение деления специалистов по уровню квалификации.
Я давно придумал условный «круг компетенций», который показывает рост компетенций аналитика во времени при получении нового опыта.
Здесь четыре уровня – я сейчас по ним кратко пробегусь, чтобы было понятно.
Самый первый уровень – стажер. У него нет никаких специальных знаний, это обычный адекватный человек, который умеет:
-
общаться;
-
писать, говорить;
-
работать на компьютере в каких-либо редакторах;
-
документировать полученную информацию
Этого достаточно, чтобы испытать себя в профессии. Но, стажер сам работать не может. Он перенимает опыт у одного из аналитиков и решает для себя, получится у него дальше расти или нет.
Далее человек приобретает опыт, начинает развиваться и доходит до следующего уровня.
На втором уровне:
Аналитик уже знает архитектуру информационной системы с точки зрения ее использования – понимает, как работает типовая конфигурация. Он начинает общаться с пользователями, собирает и формализует их требования. Обладает навыками проектирования интерфейсов, ставит задачи разработчикам, начинает тестировать систему.
К сожалению, большинство аналитиков на этом этапе останавливаются и дальше не развиваются, потому что считают, что это не надо – остальным должны заниматься другие люди, программисты или, например, архитекторы.
Но это неправильно. И на этой стадии многие начинают выгорать, потому что не создается условий для дальнейшего роста, люди попадают в рутину проектной работы с однотипными задачами. Хотя дальше, конечно же, есть прекрасные возможности роста.
Переход на третий уровень означает, что:
Появляется знание методологий учета – если нужно общаться с главным бухгалтером, нужно понимать все эти процессы. Знание нотаций описания бизнес-процессов, специалист уже умеет моделировать систему и четко понимает, что можно сделать, а что нельзя, управляет требованиями на всех этапах. Понимает архитектуру, может открыть и прочитать код, понимает алгоритмы и строит запросы.
К следующему этапу – эксперту – двигается очень низкий процент людей.
Здесь появляются знания в отраслевой специализации, принципы функционирования бизнеса, анализа и реинжиниринга процессов.
Эксперт – это уже человек совершенно другого уровня. И доходит до того, что уже он может оказывать влияние на возникновение требований: он обладает таким авторитетом, что общается с директорами и топ-менеджерами на одном языке. Если он говорит, что бизнесу это не надо или надо сделать по-другому, ему верят. Он может оказывать влияние в том числе и на масштаб проекта.
Что происходит дальше? После того, как человек всем этим уже овладеет, ему становится некуда расти, и он меняет род деятельности.
-
Не обязательно он уходит из профессии, самый простой путь – начинает руководить другими бизнес-аналитиками, тренирует их и помогает растить.
-
Бывает, что люди становятся руководителями проектов. Это самые хорошие руководители проектов, и пользы от них больше, чем от тех, кто прошел 10 курсов по управлению проектами, но ничего не понимает в бизнес-анализе. Научить управлению проектами такого человека очень легко, потому что он уже хорошо понимает, как управлять людьми, как управлять процессами и их оптимизировать. Хорошо понимает, как работает тот или иной бизнес. Поэтому ему гораздо легче планировать проект, и он гораздо лучше понимает, какие приоритеты у бизнеса, чем просто администратор, который занимается управлением проекта.
-
Есть и третий вариант – уход в менеджмент. Очень часто таких людей забирают в топ-менеджмент. Это кстати мой случай. Я после бизнес-анализа работал некоторое время руководителем проектов, затем несколько лет руководителем разного уровня.
Какими качествами должен обладать аналитик и почему «не всем дано»
Поговорим о качествах, которыми должен обладать аналитик. Под качествами я имею в виду не знания, а образ мышления человека, который либо дан, либо нет.
Я постарался выбрать 10 самых важных качеств – можете проверить, есть ли они у вас. Если вам эти качества близки, значит, у вас большие шансы стать хорошим бизнес-аналитиком и развиться до высокого уровня. Если большей части этих качеств у вас нет, то, скорее всего, дойдете только до второго уровня, максимум третьего. Дальше будет все сложнее и сложнее.
Но эти качества тоже вырабатываются со временем.
Кратко расскажу о самом важном.
-
Системность мышления – умение разложить все по полочкам, проанализировать, найти все связи. Такое мышление у человека должно быть по жизни.
-
Высокоразвитые коммуникативные навыки. Человек не только должен уметь говорить, но и управлять беседой, спором. Он должен владеть письменной и устной речью, четко формулировать свои мысли, уметь проводить переговоры.
-
Специалист должен любить учиться. Образование и обучение должны быть непрерывной частью его жизни. Если в школе и институте он не любил учиться, то, скорее всего, ему будет сложно двигаться дальше.
-
Очень важное качество – вариативность поиска решений. Этому нигде не учат. Но, если появилась задача, и человек сгенерировал одно решение, потом сразу же второе, третье – это очень важно. Эта альтернативность в подходах обязательно нужна.
-
Очень важны навыки решения проблем – если появились проблемы, человек не должен впадать в ступор, он должен начинать их решать.
-
Конечно же, обязательно владеть навыками приоритезации.
-
Уметь работать в режиме многозадачности. Далеко не все это могут, тут должен быть особый стиль мышления. У бизнес-аналитика может быть много разных задач, иногда не связанных друг с другом, и всеми ими надо заниматься. Управлять ими и все это держать в каком-то зафиксированном виде.
-
Человек должен обладать высоким уровнем самоорганизации – здесь я подразумеваю тайм-менеджмент и систему управления задачами, в дополнение к многозадачности.
-
Человек должен любить использовать ИТ-инструментарий. Это очень важно, потому что прошли те времена, когда мы занимались бизнес-анализом на бумажке. Специалист должен учиться пользоваться ИТ-инструментами – если ты не дружишь с компьютером, быть аналитиком у тебя не получится никак. Надо пробовать разные инструменты, подбирать для себя подходящие.
-
Человек должен уметь все записывать и фиксировать, а не держать это в голове. Об этом написано много книжек.
Выгорание аналитиков
Бизнес-аналитик – это очень интересная профессия, и, как показывает практика, люди сами не выгорают.
Если все нормально организовано, то у специалистов очень высокая степень разнообразия: часто меняются заказчики и руководители, меняется работа территориально, постоянно появляются новые задачи из разных отраслей. Плюс есть возможность вертикально развиваться и обучаться.
Поэтому в нормальной ситуации выгорание происходит очень редко – это хорошая профессия, ее можно любить и долго в ней развиваться.
Но, случается, что, бизнес-аналитиков “выжигают”. Это происходит по двум причинам:
-
Первая - их выжигает сам менеджмент (руководители компании или руководители проектов). К примеру, есть специалист Вася, который идеально пишет инструкции, все пользователи счастливы. Но ему уже надоели эти инструкции, ему хочется чего-то другого. Но его убеждают, что ему надо продолжать инструкции писать, потому что это у него получается идеально.
-
Вторая причина – плохая организация работы внутри проекта, и виноват в этом руководитель проекта. Если руководитель низкой компетенции в понимании, как управлять проектом, конечно, аналитика это очень сильно выбивает. Буквально 2-3 проекта с таким руководителем, и бизнес-аналитик выгорает.
Вопросы
Есть ли какие-то наработки, тесты, задания, которые позволяют достаточно быстро определить, есть ли у человека потенциал к бизнес- или системному анализу? Например, как это выявить на собеседовании?
Конечно, это можно выявить, ничего тут сложного нет. Конкретно я разработкой тестов не занимался, но при общении с партнерами я слышал про такие тесты. Они существуют.
Самое простое – дать кандидату кейсы на решение какой-то бизнес-задачи и технической задачи – например, спроектировать структуру метаданных для конфигурации. И посмотреть – если человек использует регистры там, где нужно использовать справочники, ясно, что он просто не знает.
Но, это будет тест на его знания, а не на его потенциальные возможности. Поэтому здесь нужно понимать, что вы проверяете – его потенциал либо уже его знания. Это две разные вещи.
В 1С у нас есть две касты людей – программисты и консультанты, аналитики, руководители проектов. И получается, что новичок-стажер, когда решает, кем быть – выбирает стать программистом, потому что как программировать – понятно. А консультант в 1С – это творческая профессия, и непонятно, как им работать. Почему фирма «1С» все-таки не прорабатывает этот аспект?
В фирме «1С» работает много умных людей, и я уверен, что там были такие люди, которые это пытались прорабатывать. И, возможно, они снизу это лоббировали. В начале 2000-х годов даже был документ от 1С, где была приведена классификация различных ролей в проектах, и там присутствовал бизнес-аналитик – его уровни, какие-то категории. Даже планировался экзамен на специалиста-аналитика.
Потом движение в этом направлении резко прекратилось, и, судя по тому, как у нас сейчас организована система аттестации, там внутри есть какие-то внутренние противоречия. По моему мнению, они где-то в высших эшелонах управления этот процесс тормозят, возможно считают не самым важным. Поэтому создается впечатление, что фирма «1С» ничего в этом направлении не делает. Но я уверен, что она будет двигаться в данном направлении. Пройдет буквально 2-3 года, и я уверен, что там что-то родится. Потому что сейчас без этого нельзя, это уже такой тренд. Конкуренция и сложность системы растет, требования бизнеса растут. Никуда они не денутся и скоро начнут над этим работать.
*************
Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Бизнес-аналитик. Роль в команде, компетенции, инструментарий".
Приглашаем на конференции Инфостарта 2025 годаINFOSTART TEAMLEAD EVENT
Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров. INFOSTART A&PM EVENT (Анализ & Управление проектами)
Практическая конференция для аналитиков и руководителей проектов 1С. |