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

Меня зовут Александр Чавалах, я исполнительный директор Инфостарта.

Когда-то давно, до начала 2000-х годов, я несколько лет работал программистом на крупном производстве.

Потом, с 2005-го года, перешел в сферу 1С – много лет работал в партнерских компаниях на разных позициях. Работал программистом, руководителем проектов, аналитиком, директором – прошел весь этот путь и по вертикали, и по горизонтали.

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

С 2015-го года я работаю исполнительным директором в Инфостарте. На тот момент в компании было 12 человек, сейчас уже больше 100.

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

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

В 2006 году я работал в небольшой компании 1С-Франчайзи. Мы выиграли интересный тендер, довольно крупный для нас. Приходим к заказчику. На первый взгляд, там была очень простая банальная ситуация – куча переписанных баз «1С:Торговля и склад» на 7.7, с которых нужно было перейти на конфигурацию «1С:Управление торговлей» 8-й платформы. Выглядело это очень просто. Вызывало вопросы наличие совершенно разных видов бизнеса, но мы были молодые и смелые.

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

Я глубоко убежден, что описывать бизнес-процессы так, как они сейчас происходят – это бесполезная трата ресурсов и времени. Все это очень быстро устаревает и потом никому не нужно. Но задача есть задача: попросили описать «как есть», чтобы решить, что делать дальше.

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

Я взялся за эту задачу, но на тот момент плохо себе представлял, как это можно сделать. Фактически, это была авантюра. И, конечно, возникла куча вопросов: «Что делать? Как? Зачем? Где быстро научиться?»

На тот момент я только начал заниматься 1С, поэтому решил обратиться за поиском технологий, методик и подходов к вендору – фирме «1С». Мы написали туда письмо, но нам ответили, что готовых методик по описанию бизнес-процессов у них нет. Покопался в интернете, особо полезного тоже не нашел, хотя информации было много. Сейчас на дворе 2021, ситуация иная, и то далека от совершенства. А в 2006…

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

Я перерыл кучу литературы, книг, статей и нашел различные отрывки технологий от других вендоров из других компаний – посмотрел, как работает SAP, «Галактика», «Парус», еще ряд менее известных компаний. В общем, мы все эти кусочки собрали, я их синтезировал, анализировал и потом в течение двух месяцев разрабатывал технологию работы.

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

• как формировать первоначальную группу заинтересованных лиц;

• какой должен быть состав участников;

• какой должна быть технология их первичного обучения;

• как подготовить анкеты, провести анкетирование, обработать эти анкеты;

• как проводить устные опросы;

• дальше – описание бизнес-процессов, их декомпозиция, выбор нотации, построение дерева процессов и т.д.

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

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

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

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

О развитии и трансформации подходов

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

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

Прежде чем говорить о каких-то подходах к бизнес-анализу, нужно сначала определиться, что это за профессия – «Бизнес-аналитик»?

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

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

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

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

• Часть людей – в основном, это руководители, которые строят у себя в компаниях ролевую систему работы – пошли по пути чрезмерного разделения труда. То есть начали выделять некую отдельную профессию под каждую новую задачу/роль. Получилось, что вместо ролей в команде выдумывалась куча профессий – отсюда и появился у нас весь этот винегрет названий.

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

Вывод: оба варианта – плохие.

Чем отличаются бизнес-аналитик и ИТ-аналитик?

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

Судя по реакции зала – примерно 50 на 50.

Тогда посмотрим на примере. Предположим, вы приходите к заказчику, вам заказчик говорит – у меня падают продажи, я хочу CRM-систему.

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

• А как будет решать задачу бизнес-аналитик? Он сначала спросит: «А почему у вас падают продажи? Что у вас случилось? Может быть, на вас конкуренты давят? Может быть, цены неправильные?» И т.д. Возможно, вам вообще деньги нужно сейчас вкладывать не в ИТ, а в модернизацию производства – покупать новые станки, иначе бизнес через два года помрет, и ему никакая автоматизация будет не нужна.

Это совершенно разный образ мышления – бизнес-аналитик все-таки думает о бизнесе.

Я говорю это к тому, чтобы у вас было правильное понимание терминологии. Но мы сейчас к этому еще вернемся.

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

Исключения, конечно, есть. Особенно, если компания разрабатывает свой сложный отраслевой продукт, и ей нужна хорошая отраслевая компетенция. Вот эти 3-5% на рынке есть, но, как правило, настоящих специалистов по бизнес-анализу в ИТ нет. Это, конечно, проблема. Но ИТ нашло выход!

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

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

Это два таких крайних подхода, но в ИТ есть сторонники одного и другого. У Елены Ивановой есть доклад на эту тему – кого на что можно «натянуть» – бизнес на ИТ-систему, либо ИТ-систему на бизнес.

Чтобы понимание терминологии было правильным, секция на конференции называется «ИТ-Анализ», а не «Бизнес-анализ».

Тем не менее:

• Термин «Бизнес-анализ» для ИТ-систем – устоявшийся, его все используют, я его сам использую.

• Кроме этого, определение бизнес-аналитика, которое есть в BABOK 3.0, полностью соответствует тому, что делает ИТ-аналитик. Если кто не знает, BABOK – это свод знаний по бизнес-анализу. У него недавно вышла третья версия – буквально пару месяцев назад ее перевели на русский язык, полезно почитать. Так вот, в BABOK бизнес-аналитиками называются все люди, которые, так или иначе, участвуют в улучшении бизнес-процессов. По факту, это означает, что любой руководитель отдела, который занимается развитием своего отдела и изменяет бизнес-процессы, в данный момент выполняет роль бизнес-аналитика. Получается, что очень много людей в компании выполняют роль бизнес-аналитиков. И про тех людей, которые улучшают процессы в ИТ, тоже можно сказать, что они выполняют роль бизнес-аналитиков. Потому что так в BABOK определено.

• Инструменты ИТ-анализа и бизнес-анализа совпадают. И, для информации, в BABOK есть перечень техник бизнес-анализа, их там ровно 50 штук.

Особенности работы ИТ-аналитиков у других вендоров

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

Летом 2021 года мы командой Инфостарта ездили на «Летний аналитический фестиваль» (ЛАФ). Это такое мероприятие, которое происходит каждый год в разных местах на природе – где-нибудь на турбазах. У них даже логотип с палаткой.

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

Мы туда приехали с конкретным перечнем вопросов, которые нас в индустрии 1С волнуют, чтобы послушать, что нам скажут. И подумать, что к нам применимо.

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

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

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

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

Необходимые Hard-скилы ИТ-аналитика в 1С

Вернемся к Hard-скилам. Недавно я обнаружил, что большинство людей неправильно понимают, что такое Hard-скилы и Soft-скилы, поэтому уточню:

• К Hard-скилам относятся профессиональные компетенции.

• А Soft-скилы – это психологические и коммуникативные вещи.

Например, как вы думаете, русский язык – это Hard-скил или Soft-скил?

Есть единое правило, которое позволяет однозначно отнести навык к Hard и Soft-скилам.

• Любые компетенции, которые можно каким-либо образом протестировать и объективно оценить, относятся к Hard-скилам. Например, иностранец может выучить русский язык, и этот уровень подготовки можно проверить с помощью экзамена, значит, правила русского языка – это Hard-скилы.

• А Soft-скилы – это то, что измерить и оценить очень сложно. Допустим, это навыки налаживания коммуникаций, завоевания доверия и т.д.

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

У нас почему-то часто считается, что аналитик не должен заходить в конфигуратор, а если он в конфигуратор заходит, значит, это программист. Очень странное разделение. Конечно же, это однозначно нужно менять.

ИТ-аналитик 1С должен обладать стандартным набором скилов для аналитика – об этом у Анастасии Штей есть отдельный доклад:

• Аналитик должен уметь читать код. Он не должен программировать, он не пишет код. Но, если он в конфигураторе видит код, он должен понимать примерный смысл и логику.

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

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

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

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

• И, конечно же, он должен уметь проектировать интерфейсы в конфигураторе.

Прототипирование интерфейсов

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

Сейчас вы поймете, почему это логично, и почему 1С-аналитикам эти скилы нужно прокачивать.

На упомянутом «Летнем аналитическом фестивале» у нас был круглый стол, где мы обсуждали проектирование интерфейсов. В том обсуждении участвовали люди из SAP, из ORACLE, из Directum, из заказной разработки, и один человек был из 1С. Говорили о применяемом инструментарии.

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

• Figma;

• Balsamiq;

• MS Visio;

• скрин экрана и дорисовывание полей в простейшем редакторе типа Paint;

• а кто-то вообще чертит прототип на бумаге и потом несет разработчикам.

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

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

Причем, прототипировать 1С-подобный интерфейс можно и в Figma – пример подобного прототипирования показала в своем докладе Мария Серегина.

Кросс-функциональность команд

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

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

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

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.