Роль и задачи аналитика в проектной команде при внедрении 1С

Меня зовут Денис Галимов, я работаю в компании «Первый БИТ» руководителем отдела экспертизы. В мои обязанности входит подбор, распределение по проектам, выращивание, развитие и определение стандартов работы всех аналитиков и экспертов в нашем офисе.

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

Что касается профессии «Аналитик» или «ИТ-аналитик», то об этом много информации в интернете и в различных книгах. Поэтому мой доклад будет, в основном, про ИТ-аналитика в сфере 1С. Это не кардинальное отличие, но оно имеет свою глубокую специфику.

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

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

Кто такой аналитик

Начнем от общего – кто такой аналитик? Есть много сложных формулировок, но у меня своя вольная трактовка, которая определяет, что:

Аналитик – это специалист по изменениям.

Важно понимать, что все сферы бизнеса и вообще все сферы нашей жизни подвержены изменениям – плановым и внеплановым.

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

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

Работу аналитика можно разделить на четыре крупных этапа.

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

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

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

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

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

Что такое ИТ-проект

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

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

Соответственно, цель ИТ-проекта – это обычно увеличение прибыли либо за счет снижения затрат на ИТ-окружение, либо за счет повышения контроля, повышения эффективности каких-то процессов.

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

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

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

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

Итак, цель ИТ-проекта – это решение бизнес-задачи путем изменения ИТ-окружения.

На входе ИТ-проекта у нас обычно следующие простые вводные:

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

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

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

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

Далее я буду говорить не обо всех ИТ-проектах в принципе, а именно об ИТ-проектах 1С, потому что:

• во-первых, сама 1С накладывает специфику;

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

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

Поэтому я буду говорить именно об ИТ-проектах 1С.

Какой аналитик нужен в ИТ-проекте 1С

Вернемся к вопросу – какой аналитик нужен в ИТ-проекте 1С? Точнее, переформулируем его правильнее – для чего нужен аналитик в ИТ-проекте 1С.

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

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

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

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

Поскольку аналитик в целом– это специалист по изменениям, соответственно бизнес-аналитик – это специалист по изменениям в бизнесе.

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

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

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

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

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

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

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

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

• Следующий этап – внедрение изменения.

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

В том числе, на выходе не обязательно будет только один проект – обычно, когда бизнес-аналитик приходит решать бизнес-задачу, на выходе он выкатывает программу проектов, которая включает в себя:

• организационные проекты по изменению процессов;

• технологические проекты по изменению программного обеспечения или оборудования;

• методические проекты по изменению учета в каких-то конкретных бизнес-процессах.

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

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

Кто такой системный аналитик

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

Продуктом деятельности системного аналитика является постановка задачи на разработку ИТ-продукта.

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

Как выглядит цикл деятельности системного аналитика в контексте того же примера?

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

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

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

• Дальше ему это нужно внедрить.

Примерно так можно представить работу двух этих аналитиков в паре.

Когда и какой аналитик требуется в проектах 1С

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

Чаще всего, к нам приходят с задачей «Хотим внедрить ERP». Т.е. у них уже есть какое-то выработанное бизнес-решение, они для себя уже определились, что ERP решит какие-то их бизнес-задачи и поможет бизнесу стать сильнее, конкурентоспособнее, лучше.

Когда и какой аналитик может потребоваться в такой ситуации?

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

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

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

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

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

• и превратит представление заказчика о его бизнесе в некую систему информации, согласованную между всеми участниками этого процесса.

Когда нужен системный аналитик?

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

• Но когда у вас дома что-то ломается или вы хотите что-то к дому пристроить, вы всегда обращаетесь к профессионалам? Нет. Сначала вы пробуете справиться сами, и это тоже нормально. Поэтому изначально внутри предприятия всегда рассматривается возможность реализации изменения своими силами, и иногда компания может внедрить какие-то ИТ-изменения без привлечения профессионалов. Например, при высокой экспертизе бизнес-пользователей в используемых продуктах небольшие изменения могут быть скоординированы самостоятельно. Здесь ключевой момент – пользователи должны быть погружены в продукт и четко понимать поставленные задачи, плюс изменения должны быть небольшими. Классический кейс: есть главный бухгалтер, который ориентируется в БП 3.0, во всем разбирается. У директора появляется задача: он хочет видеть отчетность по направлениям деятельности. Бухгалтер может сама прийти к выводу, что, используя аналитику номенклатурной группы, мы получим разрез финансового результата и сможем готовить отчеты по направлениям деятельности для директора. Дальше она самостоятельно внедрит эти изменения – заведет номенклатурную группу, возможно, воспользуется какой-то групповой обработкой за прошлые месяцы этого года, перезаполнит все значения за пару ночей и обучит всех других пользователей, в каких случаях какие направления надо выбирать. Дальше проконтролирует внедрение этого изменения. Это – классический пример того, как внутри предприятия внедряются какие-то небольшие ИТ-изменения.

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

Какими знаниями должен обладать аналитик

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

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

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

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

Какие должны быть ключевые знания у системного аналитика?

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

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

• Системному аналитику еще важны технические знания об архитектуре приложений и возможностях их изменений.

• И еще – подходы и практики написания технических заданий, разработки и внедрения продуктов.

Объединение и разделение функций аналитика

Главный вопрос – это объединение/разделение функций аналитика.

В 1С у нас чаще всего нет разделения на бизнес-аналитика и системного аналитика – и это нормально.

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

• На самом деле совершенно оправданно, что эти две роли объединяют в одну, потому что недостаток понимания бизнес-аналитиком обычно компенсируется знаниями представителей бизнеса либо отсутствием требований к каким-то глобальным изменениям. Как я уже говорил, обычно эти изменения осмысляются где-то за рамками проекта 1С, к нам уже приходят и ставят конкретную задачу – поставить ERP. А задача аналитика 1С (я дальше его буду называть так), сводится к тому, чтобы понять, как заказчик видит улучшение, зафиксировать его, согласовать и дальше уже реализовать. И в таких условиях, конечно, объединение этих профессий совершенно оправдано.

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

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

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

  • Но такое разделение эффективно только при достаточном объеме деятельности, и, если мы говорим об одном предприятии, в котором всего две интеграции – ERP с бухгалтерией или ЗУП, то, конечно, там у аналитика по интеграции просто не будет достаточно работы.

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

Содержание знаний аналитика 1С

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

Поэтому расскажу, на какие факторы я разделяю знания аналитика 1С.

• Первый – это предметная область, то, с чего начинаются знания аналитика:

  • знание конкретного вида деятельности;

  • знание разных видов учета, связанных с этим видом действенности.

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

  • в идеале знать не только 1С, но и еще какие-то платформы, которые востребованы на рынке;

  • что касается решений 1С – необязательно знать все на свете, но надо знать то, что сейчас актуально.

• Третий фактор – это профессиональные навыки аналитика. Я не знаю, как назвать этот фактор правильно, но это как раз то, что определяет аналитика как профессионала. К примеру, есть люди, которые знают предметные области – это люди из бизнеса, но они не могут быть аналитиками, системными аналитиками, аналитиками 1С. Есть люди, которые знают продукты – это консультанты, преподаватели, но опять-таки они не могут быть системными аналитиками. Потому что системный аналитик – это профессия, которая предполагает внедрение продукта, и для этого нужны определенные знания и навыки:

  • умение работать с основными профессиональными инструментами (MS Office, таск-менеджеры и т.д.);

  • умение создать план реализации задачи или группы задач;

  • знание и умение готовить документацию;

  • умение собирать информацию (интервьюирование, анкетирование и т.д.);

  • умение систематизировать информацию о бизнес-процессах, требованиях, интеграционных схемах;

  • знание подходов к разработке и т.д.

Организация команды аналитиков

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

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

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

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

Архитектор – это лидер команды, и у него есть конкретные задачи:

• он вырабатывает концепцию изменений и защищает ее – он ее собирает со всех аналитиков в единую картинку и представляет перед заказчиком;

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

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

• определяет структуру проектной документации, подход к решению задач;

• контролирует качество выполняемых работ и определяет критерии приемки;

• обеспечивает целостность создаваемого решения.

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

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

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

• к примеру, готовит проектную документацию технический писатель;

• тестирует изменения и принимает изменения у разработчиков – тестировщик;

• выполняет настройку и подготовку продуктов – консультант;

• обучает пользователей – преподаватель.

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

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

Выполнение проекта

Есть две группы процессов при выполнении проекта:

• технологические процессы, которые направлены на создание и внедрение продуктов – эти группы входят в поле деятельности аналитика или архитектора;

• процессы управления проектом, которые входят в поле деятельности руководителя проекта.

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

Внизу на слайде перечислены основные стадии проекта, которые есть.

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

Я укрупненно делю проект на четыре ключевые стадии – я думаю, все вы с ними знакомы, это:

• Обследование

• Дизайн – моделирование, проектирование

• Разработка

• Внедрение

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

Выводы

Что я хотел донести своим докладом?

• В проекте 1С системный аналитик более важен, чем бизнес-аналитик, так как основная задача – это внедрение изменений в ИТ-окружении.

• Аналитик должен быть знаком со спецификой видов деятельности.

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

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

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

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

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

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

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

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

Вопросы

Хотелось бы более четко поставить границы между бизнес-аналитиком, системным аналитиком и новым понятием «аналитик 1С». Мы знаем, кто такой бизнес-аналитик, кто такой системный аналитик. А когда во все это включается 1С, что мы получаем?

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

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

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Бизнес-аналитик. Роль в команде, компетенции, инструментарий".