Это всего лишь мизерная часть заголовков, которые возвращают поисковики на запрос «бизнес аналитик».
Тем не менее, ситуация не становится яснее и споры разгораются тем сильнее, чем чаще поднимается вопрос: «Кто такой бизнес-аналитик?».
Это человек, который занимается анализом финансового состояния организации, или человек работающий в департаменте стратегического развития компании, это человек, который пишет требования для IT приложения, или человек, анализирующий большие данные…?
Люди, вступающие в споры и отстаивающие свое право называть себя «бизнес-аналитиком», или наоборот, доказывающие, что остальные не имеют никакого права называть себя этим гордым именем, являются представителями совершенно разных видов деятельности и находятся на разных уровнях служебной иерархии. Это люди, получившие непрофильное, или, как они зачастую считают, профильное образование. Это люди, которые используют совершенно разные подходы, методологии, техники, инструменты… Но, тем не менее все они считают себя бизнес-аналитиками.
Регулярные встречи аналитиков. Занятие 1 Основные понятия бизнес-анализа
Как понять, кто прав? Как разрешить этот конфликт? Где тот критерий, который позволяет нам определить, что тот или иной человек является, или не является бизнес-аналитиком?
На самом деле вопрос: «Кто такой бизнес-аналитик?» не является правильным вопросом, поскольку ответить на него очень просто: «Бизнес-аналитик – это человек, который занимается бизнес-анализом». Правильный вопрос только один, и ответ на него поможет нам разрешить сложившуюся ситуацию.
ЧТО ТАКОЕ БИЗНЕС-АНАЛИЗ?
Давайте предпримем первую попытку определить, что такое бизнес-анализ. В проекте по разработке профессионального стандарта «Бизнес-аналитик» мы сформулировали следующее определение (сразу скажу, что практически все термины, вошедшие в Глоссарий стандарта, заимствованы Руководства к своду знаний по бизнес-анализу BABOK Guide v3.0 и творчески нами переработаны)
Бизнес-анализ –это деятельность, которая делает возможным проведение Изменений в организации, приносящих Пользу Заинтересованным сторонам в определенном Контексте, путём выявления Потребностей и обоснования Решений, описывающих возможные пути реализации этих Изменений
Я думаю, что после этого, многие из нас могут сказать: «Пфф, ну теперь все стало немного понятней. ». Согласен, определение достаточно сложно воспринимается на слух, тем более если вы с ним не знакомы или еще не разбирались в нем детально.
На самом деле, это определение – это кодовый ключ, который позволит нам впредь понимать: ЧТО делает бизнес-аналитик, КАК он это делает, и, главное, ПОЧЕМУ он это делает.
Вы, наверное, уже обратили внимание, что в определении выделены некоторые слова. Это неслучайно, каждое из этих слов играет очень важную роль. Это слова, входящие в список так называемых, Базовых понятий. Совокупность этих базовых понятий образует Модель Базовых Понятий Бизнес-Анализа (МБП БА)[1].
Я хочу вместе с вами разобраться в каждом элементе этого определения, в том, как эти элементы связаны между собой, и как в результате они формируют единую Модель Базовых Понятий Бизнес-Анализа. Эта модель будет служить вам как в качестве фундамента, так и в качестве некой системы координат в которую вы будет встраивать все остальные знания о бизнес-анализе.
Вопросы на собеседовании ИТ Бизнес-Аналитика. Часть 1
Для того, чтобы наш разговор был не очень скучным, я расскажу вам историю о некоем вымышленном человеке. И на примере этого человека мы: разберемся в базовых понятиях, построим модель базовых понятий, и сможем осмысленно еще раз дать определение бизнес-анализа.
Ну, что… Готовы?
Человек – Потребности – Контекст
Прежде всего, я хочу задать вам один несколько необычный вопрос…Скажите, кто из вас сейчас, вот до этого момента, когда вы прочтете до конца этот вопрос, задумывался о том, что вам необходимо дышать.
О том, что каждые 3 секунды вам, как минимум, нужно сделать один вдох и, соответственно, один выдох? Я думаю, что практически никто.
Чтобы ответить на этот вопрос давайте представим себе некоторого воображаемого человека, у которого, так же, как и у всех остальных живых существ, есть Потребности. В частности, Потребность дышать (см. рис.1).
Источник: alex-belin.wixsite.com
лекции ИС / Бизнес-анализ
Только сегодня: 300 рублей в подарок на первый заказ.
Какую работу нужно написать?
Другую работу
Помощник Анна
Бизнес-анализ (англ. business analysis) — дисциплина выявления деловых потребностей и нахождения решений деловых проблем. Решения часто включают компонент разработки систем, но могут также состоять из усовершенствования процессов, организационных изменений или стратегического планирования и разработки политики. Человека, который выполняет эту задачу, называют бизнес-аналитиком.
Тех бизнес-аналитиков, которые занимаются исключительно разработкой программных систем, можно назвать IT бизнес-аналитиками, техническими бизнес-аналитиками или системными аналитиками. Бизнес-анализ это навигатор в бизнес -пространстве, который помогает объединить данные из всех информационных источников компании и моментально анализировать их с помощью единого инструмента.
Большинство компаний постоянно собирает, создаёт и накапливает значительные объемы информации. Поставщики, закупочные цены, даты продаж, место продажи. Необходимо лишь оперативно получать ее в нужный момент по простому запросу.
Без специального инструмента сделать это практически невозможно — требуемые данные собираются из разных отделов, и их хранение происходит разрозненно проанализировать и просмотреть всё одновременно достаточно затруднительно. Система бизнес -анализа, позволит получить моментальный доступ к сохраненным данным, представит необходимую статистическую и аналитическую информацию.
В первую очередь это инструмент для маркетологов, финансистов и аналитиков, а также средство формирования отчетов для руководителей фирмы. Однако руководители информационных служб не смогут использовать истинный потенциал и ценности систем бизнес-анализа на полную мощность до тех пор, пока эти средства не станут повседневным инструментом для каждого сотрудника организации.
После представителей высшего руководства преимущества систем Бизнес анализа должны оценить менеджеры по продажам. Поскольку цель их работы заключается в увеличении оборота компании, и зарплата, как правило, непосредственно определяется успехами, достигнутыми на этом поприще, им просто необходим инструмент, который поможет им добиться более высоких результатов – при условии, что соответствующий инструмент достаточно прост в использовании, а полученной информации можно доверять.
Каждый сотрудник получает оперативный доступ к полной и актуальной информации обо всей деятельности предприятия с учетом существующих прав доступа к закрытой информации. А так как — информация собирается со всех отделов, офисов и подразделений в автоматическом режиме — менеджмент и персонал получают единый инструмент контроля базы данных.
Расхожее мнение, что бизнес-анализ нужен только для крупных компаний, в корне не верен. Небольшая компания, где все решения принимает руководитель, а ИТ-служб вообще нет, без четкого анализа ситуации на фирме может потерпеть значительные убытки, есть большая вероятность того, что информация «со склада до бухгалтерии» дойдет с некоторым, пусть с не большим но опозданием, что чревато не правильно сформированными отчетами или не вовремя выплаченными налогами, что повлечет за собой потерю времени и денег, и в корне не верное представление руководителя состояния дел на фирме.
В крупных компаниях моментальный доступ к финансовому анализу состояния фирмы позволит руководителям ИТ-служб заняться более тщательным изучением бизнес-процессов и анализом возможности их дальнейшего улучшения с помощью имеющихся данных. Компании, использующие системы бизнес-анализа для выявления изъянов в бизнес-процессах, имеют гораздо более высокие шансы на повышение своей конкурентоспособности по сравнению с организациями, в которых системы бизнес -анализа служат только для контроля за тем, что происходит.
Можно много рассказывать абстрактно, для чего необходим бизнес-анализ на фирме, но у меня есть два примера из личного опыта, которые очень наглядно показывают, что теряет конкретная фирма, используя устаревшие методы сбора информации. Я работала промоутером в крупной сигаретной компании (для привлечения новых потребителей проводилась компания — подарок в обмен на покупку) первое недоумение у меня вызвала отчетность, промоутерам выдавалось 8 листов бумаги формата А4.
На первом листе мы должны были записывать новые подарки которые мы берем со склада, пять листов для ежедневной отчетности, на этих листах мы писали сколько подарков конкретно в день работы мы подарили, и какие сигареты курит человек которого я уговорила купить нашу марку. 7-ой лист остатки подарков, которые у нас на руках, после недели работы.
8-ой лист общий отчет по маркам сигарет которые курили наши клиенты- это для маркетологов. Все отчеты сдавались супервайзеру , после проверки он отдавал последний лист в маркетинговый отдел.
Самый главный недостаток, для промоутера это огромное количество времени которое затрачивалось на формирование недельного отчета, так как это все на бумаге и потерять пачку сигарет или подарок составляя отчетность ничего не стоило, недельный отчет с остатками подарков на руках сходился раза с четвертого. И все равно несчастный супервайзер тратил на проверку этих отчетов всю ночь.
Очень не люблю всю эту бумажную волокиту, я составила программку в еxcel, в которой мне вручную нужно было только вбить полученные подарки со склада, и ежедневный отчет. Недельный отчет для отдела маркетинга и отчет по остаткам подарков на руках формировались сами.
Первое, что я заметила после того как дала отчет супервайзеру, а он разослал это всем промоутерам – то что отчеты стали более разнообразные (промоутеры, что бы не путаться в бумажных отчетах просто ставили 3-4 марки сигарет) не доносили всю информацию до маркетологов. Хотя маркетологи могли бы и заметить, что не может вся Москва курить всего 3 марки сигарет!
Второе – наши еженедельные собрания стали длиться не 4 часа, а минут 30 . Мы не формировали отчеты перед собранием, а просто сбрасывали всю информацию супервайзеру в электронном виде. И приезжая на еженедельные собрания, мы просто брали подарки на неделю и составляли график работы. И третье и самое важное, маркетологи анализировали изначально неверную информацию, так как супервайзер в день работает 4 часа, отчет идет за этот четырех часовой период, а на самом деле, супервайзер может простоять 3 часа подарить всего 3-4 подарка, а за последний час сделать весь необходимы план по подаркам 20-30 штук, Так как этот час приходится на то время когда люди идут с работы. При грамотном бизнес-анализе таких недоработок просто не было бы.
26.05.2015 265.28 Кб 33 Информационная система классификация.mht
Ограничение
Для продолжения скачивания необходимо пройти капчу:
Источник: studfile.net
Модель основных понятий бизнес-анализа
Буквально вчера вышел в свет второй номер журнала Российских Бизнес Аналитиков и начинается он со статьи Георгия Савельева «Сущность биpнес-анализа», в которой, в частности, речь идет о новой модели компетенций бизнес-аналитика. Мне очень нравится как Георгий рассказывает о бизнес-анализе и особенно о том, что его назначением является выявление и устранение неопределенности, а результат деятельности аналитика не картинки и тексты, а ментальные модели, обеспечивающие понимание.
Обязательно посмотрите эту статью. От себя лишь добавлю несколько слов о новой модели ключевых понятий Business Analysis Core Concept Model (BACCM). Может показаться, что она слишком сложная, особенно по сравнению с предыдущей из 2-ой версии BABOK Guide. Прежняя модель включала всего три понятия: предметная область, решения и требования.
В новой модели их шесть и среди них есть такие непонятные слова как needs, values, changes. Зачем все это надо? И так ведь все понятно. Аналитик собирает требования у заказчика и транслирует их разработчику. На самом деле, это очень упрощенная модель и на практике все выглядит совершенно по-другому.
Разработчики с утра до вечера правят баги и пишут новый функционал. Сорокачасовой рабочей недели им ясно на это не хватает. Заказчик все равно не доволен. Вместо обещанного решения от ИТ он получает проблему. Очередь из запланированных доработок выстраивается на несколько лет вперед. Все начинают искать виноватых.
Сначала на эту роль назначают тестировщиков, не способных обеспечить должное качество ПО, потом разработчиков, но в результате добираются и до аналитиков. И вот уже никто не сомневается в том, что истинная причина всех проблем в плохих требованиях. Я выскажу крамольную мысль, но причина не в требованиях.
Требования никогда не бывают полными непротиворечивыми, однозначно трактуемыми и т.д. как того требует IEEE-830. Причина в том, что стоимость внесения изменений превосходит ту пользу, которую заказчик от них получит. Проще говоря, мы тратим больше, чем зарабатываем и единственный адекватный вопрос в такой ситуации: зачем мы все это делаем?
В этом нет ничего нового. Экономически обосновать затраты на разработку ПО всегда было сложно. И есть достаточное количество публикаций с данными о том, что затраты на ИТ не окупаются. Но давайте не будем спешить. Если в организации налажен процесс проектного управления, то она не станет инициировать проекты не имеющие положительного бинес-кейса.
Скорее всего, и у нашего проекта с экономикой когда-то все было не плохо. Что же случилось и почему сейчас все стало так сложно? Для того чтобы раскрыть ответ на этот вопрос мне понадобиться простая картинка. По оси X(время) мы будем отмечать появление релизов нашего ИТ-решения. На оси ординат мы отобразим сразу два параметра: ценность, которую приносит заказчику наш продукт и затраты на его создание, доработку и поддержку.
В первой версии системы у нас все хорошо. Мы, как люди опытные, реализовали в ней наиболее приоритетные требования. Принцип Парето никто не отменял и реализация 20% таких требований приводит к получению 80% процентов выгоды. Ценность решения для заказчика очевидна, да и мы не сильно перетрудились. Премии, шампанское, статья в районной газете.
К версии номер 2 ситуация немного меняется. Все висящие низко яблоки(quick wins) мы уже сорвали, а так как при запуске сильно спешили, то сорвали вместе с ветками. Остались более сложные и менее важные требования от первой версии, появилось какое-то количество новых требований и возникших в ходе эксплуатации пожеланий.
В системе накоплен некоторый технический долг и изменения стало вносить сложнее. Постепенно утрачивается экспертиза, т.к. ключевых людей вытаскивают на другие проекты. Но желание долгосрочных отношений с заказчиком и опыт прошлых побед помогает нам справиться и со вторым релизом.
Релиз номер 3. Осень. Солнце уже не светит так ярко, опадает листва, птицы улетают на юг, а наши боссы уже включили выручку от этого релиза в годовой план по прибыли. Заказчик особо ничего не хочет. Ему осталось сделать косметические изменения, чтоб получить последние 10% ценности. Если это случится, то проект будет признан экономически успешным.
Разработчики понимают, что система получилось не очень хорошей. Самые неугомонные из них вынашивают идею большого рефакторинга. Когда о том что, по мнению программистов, самое время заново переписать всю систему узнает заказчик, он впадает в ярость. Поэтому реализуем требования заплатками и костылями. К этому времени «умные» с проекта уже соскочили и, в отличии от нас, Новый год они будут встречать дома с семьей.
Как не попасть в ситуацию номер 3 и что делать, если она все же случилась. Воздержусь от банальных заявлений о том, что в релизе номер 1 надо было думать об архитектуре, создавать повторно используемые компоненты, писать тестовые скрипты и документацию. Это уже неактуально.
Вот что действительно следовало сделать с самого начала, так это научиться измерять наши затраты и выгоды заказчика. Не обязательно в деньгах, можно и в любых других попугаях. И делать это должен бизнес-аналитик, причем не от релиза к релизу, а на регулярной основе. Сидеть вместе с бизнесом и методично измерять его пользу (см. Верните аналитика в бизнес).
Тогда хоть можно попытаться уклониться от ненужного релиза.
Что делать если релиза номер 3 не избежать? На самом деле, в такой ситуации нет ничего из ряда вон выходящего. Люди, которые занимаются крупными B2B продажами, сталкиваются с ней постоянно. Обычно им надо продать решение на несколько миллионов долларов. А удовлетворение потребности заказчика в автоматизации позволяет заработать несколько тысяч.
Казалось бы задачка не решаемая. Вовсе нет. С точки зрения продаж ситуация номер 1 существенно хуже. Заказчик знает чего хочет и может себе это позволить. Он контролирует ситуацию.
Скорее всего, конкретную сделку закроет тот, кто предложит наименьшую цену, что всегда рискованно и не особо выгодно с точки зрения экономики. Однако, наш опыт подсказывает, что компании регулярно покупают ИТ-решения на миллионы долларов. Почему так происходит? Все дело в откатах … нет, в технологии продаж и предпродажной работы.
Продавцы крупных ИТ-решений хорошо понимают, что высказанные клиентом потребности это только часть айсберга и при умелой работе можно насобирать потребностей не на один миллион. Чем они собственно и занимаются в ходе presale.
Предлагаю вернуться к статье Георгия Савельева и найти в ней цитату Марка Твена: «Проблемы создает не то, чего мы не знаем, а известное нам наверняка, которое на деле таковым не является». Продавцы работают «в голове клиента» с его ментальной моделью, перестраивая её в свою пользу. Аналитик мог бы делать то же самое, но на порядок профессиональней, если бы не был занят конспектированием очередной порции требований. А тем временем все новые «вкусные» требования уходят в соседний проект. А если они окажутся слишком сложными или не очень нужными, то их тоже перенесут на релиз номер 3.
Конечно, все что я описал выше, в некотором роде, гипотеза, требующая проверки и подтверждения в реальных проектах. Но о словах needs, value, solution, определенно стоит задуматься. Уверен, что и другие статьи во втором номере журнала российских бизнес-аналитиков окажутся не менее интересными. Планирую со временем прокомментировать их в своем блоге. Большое спасибо авторам и участникам выпуска журнала.
Источник: mxsmirnov.com