Рынок ИТ: итоги 2019

Рынок ИТ: итоги 2019 Аналитика

Основная часть

Общаясь с БА и СА из различных по размеру компаний и проектов, я увидел разлад в понятиях, который рождает споры. Как это обычно бывает, отсутствие общепринятой терминологии, мешает распределению задач и ответственности в проекте между теми, кто способен их выполнять с наибольшей эффективностью. Чтобы апеллировать к объективному источнику в этих спорах, я решил поискать мнения в сети.

Делюсь результатами своих поисков.

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

Почему именно такое разделение

Навыки, требуемые БА и СА верхнеуровнево схожи, но дьявол кроется в деталях. Системному аналитику требуется намного больше практических технических навыков для полноценной деятельности, он гораздо ближе к группе технических специалистов и должен лучше понимать их язык (без этого сложно добиться уважения в коллективе, а значит, невозможно транслировать свое видение).

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

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

При этом есть и ограничения. У БА — это рамки доменной или изученной отрасли (например: глубокое знание правил банковской деятельности), у СА — технологий и системы (например: выдающийся опыт работы с продуктами oracle). Эти ограничения могут быть препятствием при переходе между командами, проектами и компаниями, но быстро устраняются при желании и помощи коллег.

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

Это не нарушает правила, а говорит о совмещении ролей, уровне зрелости и ценности конкретного специалиста. В случае опытного работника — это вполне нормально, но странным выглядит вакансия «junior BA» со знанием SQL, JS и API на всем известном сайте.

Дополнительный анализ:  Аналитик назвал россиянам наиболее выгодную альтернативу пенсии: Пенсия: Экономика:

Абстрактный пример:

Иван — БА компании «Исполнитель».

Ева — системный аналитик компании  «Исполнитель».

Компании «Заказчик» нужна крупная доработка имеющейся системы. 

В этой ситуации задачи Ивана (БА): выявить функциональные и нефункциональные требования Заказчика и Исполнителя, устранить противоречия между заинтересованными лицами для  определения  приемлемого решения, создать прототипы, взаимодействовать с заказчиком процессе разработки, осуществить демо-показ и приемку работы. Делать все это сообща с Евой.

Задачи Евы (СА): спроектировать доработку оптимальным образом, описать ее влияние на систему, ограничения и возможные улучшения, создать спецификацию, декомпозировать и передать в разработку задачи, проконтролировать их своевременное выполнение в соответствии с требованиями. Делать все это сообща с Иваном.

Внедрение решения

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

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

Также зачастую аналитик готовит данные либо формирует требования по их преобразованиям.

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

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

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

Выявление контекста и ограничений

Разумеется заказчик находится в какой-то ситуации и он ограничен принятыми ранее  решениями (decision).

“Разгрузить грузовик” – это сложно? Неясно, так как неясен контекст.

К примеру, “Разгрузи грузовик в минус 40, на дне озера” и “Разгрузи грузовик в плюс 25, на асфальте” выглядят как совершенно разные задачи.

Для проектирования модели нужно разобраться в контексте того, как полученное решение (solution) будет использоваться, в каком процессе и для чего. Какая ситуация у заказчика. 

Выявление контекста – сфокусировано на области, где проявляют себя потребности. Нет смысла начинать решение задачи с “описания текущих процессов”, если не сформулировано цели (потребности, боли) изменений. Процессов и деталей этих процессов слишком много, их изучение само по себе без цели не имеет смысла и окончания.

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

  1. Сделать к “черной пятнице”, 

  2. Сделать, потому что каждый день мы что то теряем, 

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

Таким образом выявляются ожидания/ограничения по срокам.

Не всегда все нужно делать монументально, часто бизнес не уверен в будущих выгодах. В этом случае стоит сделать более быстрое/менее качественное решение, чтобы проверить гипотезу. Также иногда лучше сделать менее качественно, но более быстро, даже если это “заплатка” или “костыль”. Нужно выявить ожидания/ограничения по качеству.

Дополнительный анализ:  Аналитика как конкурентное преимущество, Том Дэвенпорт | Лучшие книги о бизнесе, Издательство БэстБизнесБукс, BestBusinessBooks

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

В итоге, складывается понимание ограничений на проектный треугольник (стоимость/сроки/качество).

Кроме того, область решений (solution) ограничена еще:

  1. Ограничениями по ресурсам

  2. Требованиями удобства пользователей

  3. Решениями по существующему ИТ-ландшафту и уровню ИТ сервиса

  4. Выбором подрядчиков и правилами привлечения новых

  5. Правилами работы с подрядчиками

  6. Требованиями безопасности и распространения информации

  7. Требованиями регуляторов

  8. И т.д.

Не зная ограничения, нельзя спроектировать решение с их учетом.

В случае слишком жестких ограничений решения может и не найтись. Тогда ограничения заменяются функциями штрафа и аналитик ищет наименее болезненное решение.

Выявление потребностей и целеполагание

Пациент приходит к доктору и требует “Выпишите мне аспирин, срочно!!!”.

Требование = “Выписать аспирин”. Что делает доктор в данном случае? Плохой доктор даст аспирин. Хороший доктор будет выявлять причины проблемы и лечить их.

Требование (requirement) – это некоторый образ или свойство результата, который кто-то у кого-то требует. “Выпишите аспирин”, “Программа должна делать это” – это требование. Термин не самый удачный в русском языке, он плохо стыкуется с бытовым толкованием, что запутывает заказчика и аналитика.

Требование лежит в области решения (solution). “Поесть в ресторане”, “Приготовь еду” – это требования.

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

Поэтому аналитик выявляет потребности и проектирует решение (требования к решению). 

В разное время разные бизнесы стремятся к оптимизации разных атрибутов качества своих систем и процессов.

  1. Обеспечить функциональность

  2. Качественную работу

  3. Скорость/Производительность

  4. Безопасность

  5. Низкие издержки

  6. И т.п.

Разрыв ожиданий и реальности атрибутов качества создает проблему, которую нужно решить, и для этого нужны какие-то изменения. Устранение разрыва будет целью (goal) будущего изменения.

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

Допущения

В этой статье говорится больше про ИТ-сферу.

Рассматривается «дистиллированное» значение должностей. В реальной жизни, особенно в командах, где развивают T-shaped skills (модель развития у сотрудника компетенций из смежных профессий), всё сложнее и запутаннее, но, если ваш аналитик не многоликий Янус, то переход между разными обязанностями представляет непростую задачу.

Как реагируют компании

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

Дополнительный анализ:  🥇 Лис лабораторная информационная система

«Если в прошлом году, до пандемии, местонахождение кандидата имело значение и его зарплата была сильно ниже в регионах, то на текущий момент такого уже нет, — подтверждает Иванчихина. — Фактически кандидат из Екатеринбурга может стоить таких же денег, как этот же кандидат в Москве».

Курс «hr-аналитика и автоматизация»

Владение инструментами HR-аналитики — одно из главных требований для современного HR. Этот курс даст вам преимущество на рынке труда — вы сможете быстро погружаться в работу в компаниях, где уже используется HR-аналитика, или выстраивать процессы с нуля.

Вы научитесь опираться на точные данные, а не на предположения, сократите расходы за счёт эффективной настройки HR-процессов, узнаете, как увеличить эффективность и производительность сотрудников.

Курс «аналитик данных с нуля до трудоустройства»

Аналитик данных проводит статистические тесты, чтобы решить бизнес-проблемы, на которые пока нет ответа. Он работает с разными инструментами анализа, не ограничиваясь готовыми решениями и системами. Знает языки программирования и формулирует гипотезы.

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

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

Курс «бизнес-аналитик»

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

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

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

Курс «веб-аналитика для маркетолога»

На курсе вы научитесь настраивать и собирать данные из систем аналитики, работать с Google Tag Manager, Data Studio, Google Optimize и проектировать сквозную аналитику

Сможете принимать решения об эффективности маркетинга на основе данных и находить точки роста для бизнеса.

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

Курс будет полезен:

  • HR: рекрутерам, C&B, T&D и специалистам по кадровому делопроизводству;
  • HR business partner, HR generalist, HR-директорам;
  • начинающим аналитикам и консультантам по аналитическим решениям.

На курсе вы научитесь:

  • работать с SQL (научитесь писать запросы, работать с данными в базе без переноса в таблицы, загружать данные и сохранять историю, работать с разными форматами файлов);
  • использовать Python или R (научитесь получать данные из внешних источников, обосновывать выводы, работать с массивами данных и находить закономерности в цифрах);
  • применять data-driven подход (проводить A/B-тесты и определять, что приносит результат в исследуемой области, основываясь на данных, а не на интуиции);
  • работать с Big Data (освоите актуальные инструменты анализа данных и получите явное конкурентное преимущество — крупнейшие компании работают с большими данными);
  • визуализировать данные для разной аудитории (научитесь строить графики и диаграммы: от простых до интерактивных, сможете создавать визуализации под любой тип данных и рассказывать историю, основываясь на них);
  • развивать эмоциональный интеллект (узнаете, как принимать эмоции и управлять ими, сможете лучше понимать окружающих и строить деловые отношения, усилите свою конкурентоспособность).

Продолжительность: 12 месяцев.

Старт: 23 июня.

Стоимость: ₽160 000 (без учета скидок на сайте и по промокоду DEVBY5).

Записаться

На курсе вы:

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

Продолжительность: 10 дней.

Старт: 12 июля.

Стоимость: бесплатно.

Записаться

Понятия потребность и требование

В анализе и проектировании аналитик работает с двумя областями. Область потребностей = нужд (needs) и область решений (solution).

Закрыть одну потребность можно разными способами. Каждый способ имеет разные атрибуты качества. Поесть в ресторане быстрее и вкуснее, но купить продукты в магазине, приготовить и съесть что-нибудь дома дешевле.

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

Задача аналитика в поиске и выборе наиболее подходящего для заказчика способа решения (solution) его боли и проблемы.

Проблема

У некоторых моих знакомых, коллег, руководителей, эйчаров, представителей «бизнеса» в головах образовалась путаница между видами аналитиков. Понятие «аналитик» используется для совсем не похожих друг на друга профессий — бизнес-аналитик (БА), системный аналитик (СА), дата аналитик, UX-аналитик, аналитик информационной безопасности, аналитик бизнес-процессов и ещё 5–10 других, все эти виды имеют массу различий. Сейчас про конкретные два, наиболее спутанные между собой, но сильно различающиеся в отечественных IT-реалиях.

Кому будет полезна эта статья:


В общем, «Счастье для всех, даром»

Проектирование решения

Аналитик создает непротиворечивые, полные, проверяемые модели, отражающие какой-то срез или “проекцию” будущей системы для согласования с стейкхолдерами и для принятия управленческих решений (делаем так/изменяем/не делаем). Наиболее полная модель – это реализованная система, но часто достаточно меньших усилий для получения нужных ответов на вопросы.

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

Моделей системы может быть несколько (и довольно много), но типовые это

  1. Функциональная модель, отвечающая на вопрос “как это работает, функционирует, обеспечивает функцию”. 

  2. Конструктивная модель, отвечающая на вопрос “как это сконструировано, из каких частей состоит”. 

  3. Географическая модель, отвечающая на вопрос “где это работает” или “где расположены части” делается совместно на основе предыдущих двух.

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

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

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

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

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

ИТ аналитику в поиске помогают

  • Знание того, как ИТ решают задачи по улучшению процессов, 

  • Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

  • Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

  • Знание предметной области,

  • Знание процессного управления и процессов управления изменениями,

  • Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

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

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

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

“Дайте мне аспирин” 
“А это вылечит вашу боль?”
(неизвестно, если причина боли не диагностирована)

Проектирование требований

Выявленные потребности в выявленном контексте дают возможность начать проектировать будущее решение.

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

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

Создаем требования на инструменты. Я требую инструмент с нагреваемой емкостью. Имея инструмент (а также масло и соль) я могу пожарить картошку.

Какая емкость? Какого объема? Неясно, требований не достаточно.

Дополняем потребность из контекста – мне нужно готовить в среднем на два человека. Требование – емкость объемом один литр (такие требования иногда называют нефункциональными).

Каким образом будет подаваться энергия в инструмент? Ограничением будет использование только существующих источников энергии. У нас дома электричество, есть кухонная плита, но газа нет. С учетом этого появляется требование – использование электричества или кухонной плиты, как источника энергии.

Работа

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

Опыт в области анализа и/или построения систем отчетности банка (обязательной или управленческой). − Опыт работы с большими объемами данных. −

Резюме

Работа аналитика это превращение проблем в задачи, при котором характерны этапы:

  1. Выявление потребностей и целеполагание,

  2. Выявление контекста и ограничений,

  3. Проектирование требований,

  4. Проектирование решения,

  5. Внедрение решения.

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

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

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

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

P.S. Спасибо участникам КиФБ за отзывы и корректировки к статье, а так же отдельное спасибо Денису Бескову и Анатолию Левенчуку за то, что помогли взглянуть на проблему системно

Вместо вывода

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

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

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

Если сложность проекта требует наличия БА и СА, то для начала следует сформировать понятие, какой уровень знания бизнеса и технических особенностей нужен от специалиста и транслировать его в публикуемую вакансию, стратегию собеседования и тестирования.

Коллегам, нашедшим себя или планирующим работать БА или СА, советую провести такую же процедуру и честно понять для себя, хотите ли вы (1) искать зерно истины в часто не поддающемся алгоритмам и логике, постоянно изменяющемся бизнесе или (2) исследовать и проектировать сложные, запутанные, но интересные системы.

Рынок ит: итоги 2021

В 2021 г. мировой ИТ-рынок вырос на 0,5%. Аналитики предрекали ускорение роста в 2020-м почти до 4%, однако COVID-19 заставил их изменить прогнозы, теперь их прогноз — падение на 8%. Российский сегмент в прошедшем году вырос на 7% до $25 млрд., однако по причине эпидемии в 2020 г. может упасть на 30% в рублях. Выручка 100 крупнейших российских ИТ-компаний рейтинга CNews росла в 2021 г. в два с лишним раза быстрее рынка в среднем, на 17,6% в долларах и на 22% в рублях, до ₽1566 млрд. При этом отечественный ИТ-рынок становится все более «сервисным» — на оказание ИТ-услуг приходится уже 78% его совокупной выручки. Крупнейшими заказчиками по-прежнему остаются госсектор, телеком и финансы. В списке основных трендов рост влияния государства, активное развитие инсорсинга в крупных компаниях, интерес к большим данным, усиление цифровизации в промышленности и энергетике, расширение спектра облачных услуг российских провайдеров. Надежды, связанные с «Цифровой экономикой», пока не оправдываются — старт программы откладывается на неопределенный срок.

29.05.2020

Appendix

Ну что, Главред, теперь понятнее? =)

Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector