Организация эффективного управления. Бизнес исследование


Анализ и управление – Блог для начинающих предпринимателей

Посмотреть последние материалы на главной странице блога

Задача аналитиков – стимулировать Ваше мышление, а не преподносить Вам на тарелочке способ заработать деньги.

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

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

1. Создание простого журнала учета простоев

2. Создание журнала учёта потерь производства в формате Excel

3. Универсальный шаблон для SWOT-анализа в формате Access

4. Excel-модель для анализа идеи малого бизнеса

5. Финансовый анализ предприятия (видеоурок)

NEW  Финансовая модель бизнес-плана в формате Excel(модель дополнена инструкциями по эффективному планированию бизнеса)

Полезные материалы по теме бизнес-анализа и управления

SWOT-анализ:

Что такое SWOT-анализ

Как проводить SWOT-анализ

Вопросы, на которые нужно ответить при SWOT-анализе

Пример SWOT-анализа

Разработка стратегий, исходя из Вашего SWOT-анализа

Шаблон для проведения SWOT-анализа (Word)

Реальные примеры SWOT-анализа:

Полный реальный SWOT-анализ производства биотоплива (сильные и слабые стороны, возможности и угрозы)

Универсальный шаблон для SWOT-анализа в формате Access

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

Анализ рынка методом TAM, SAM и SOM

Как установить отпускную цену для продукта

Как читать баланс финансового плана

Простые советы для достижения успеха в бизнесе

Как найти информацию о рынке для своего бизнес-плана?

Мониторинг конкурентов – как его эффективно реализовать

Что такое целевой маркетинг

Как провести анализ рынка

Как проводить маркетинговое исследование:

Анализ рынка в интернете

 

 

 

www.blogbusiness.com.ua

Как провести анализ рынка – Блог для начинающих предпринимателей

Автор: Андрей Дата: 29.11.2015 Рубрика: Бизнес-анализ, Разработка бизнес-плана

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

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

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

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

Что ж мы уже разобрались с тем, нужен анализ рынка или нет, теперь давайте перейдем к самому анализу.

Что такое анализ рынка

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

Анализ рынка и бизнес-план

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

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

Что включать в анализ рынка

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

Обзор отрасли

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

Целевой рынок

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

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

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

Конкурентный анализ

Этот раздел посвящен анализу Ваших конкурентов, и важен он сразу по нескольким причинам. Согласитесь, это очень хорошо, когда Вы знаете кому противостоите на рынке, но этот раздел также позволяет еще и выявить слабые места конкурентов. Есть ли у конкурента клиенты, которые не довольны обслуживанием? Что Вы можете предложить из того, что не предлагают аналогичные Вам предприятия?

Таким образом, конкурентный анализ должен содержать следующие компоненты:

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

Прогнозы

  • Доли рынка. Когда Вы знаете, сколько денег тратят Ваши будущие клиенты, значит, Вы можете определить какую долю рынка Вы можете захватить. Будьте практичны, но не продешевите, продавая себя. Убедитесь, что Вы в состоянии объяснить свои показатели.
  • Ценообразование и валовая прибыль. Это то место, где Вы должны описать свою структуру ценообразования и обосновать скидки, которые собираетесь предложить своему клиенту. Ваша валовая прибыль – это разница между себестоимостью и отпускной ценой. Но опять же, будьте реалистичны, не испытывайте излишнего оптимизма. При этом, однако, нужно учесть, что умеренный оптимизм в прогнозах, все же может выступать в качестве мотиватора для достижения более высоких показателей.

Правила

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

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

Если материал поста был для Вас полезен, поделитесь ссылкой на него в своей соцсети:

Проанализируйте жизнеспособность своей бизнес-идеи с помощью Excel-модели для анализа идеи малого бизнеса

И составьте свой БИЗНЕС-ПЛАН, используя упрощённый шаблон бизнес-плана в формате Excel

При использовании материалов сайта наличие активной ссылки на www.blogbusiness.com.ua обязательно

Материалы партнеров:

www.blogbusiness.com.ua

Бизнес-анализ — WiKi

Бизнес-анализ (англ. business analysis) — деятельность, которая делает возможным проведение Изменений в организации, приносящих пользу Заинтересованным Сторонам, путём выявления Потребностей и обоснования Решений, описывающих возможные пути реализации Изменений.

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

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

В данном случае бизнес-аналитик отвечает за выявление бизнес-требований по отношению к бизнес-процессам и/или бизнес-правилам, которые будут автоматизированы в рамках реализации Решения. В рамках иницииатив по разработке информационных систем (IT проекты) бизнес-аналитик тесно взаимодействует с представителями профессии "Системный аналитик".

Достаточно часто в IT проектах один человек может совмещать в своей работе обе роли, т.е. бизнес- и системый аналитик.

Разделы науки бизнес-анализа

Бизнес-анализ как дисциплина тесно связан с анализом требований, но нацелен на определение изменений для организации, которые требуются для того, чтобы организация достигла стратегических целей. Эти изменения включают изменения в стратегии, структуре, политике, процессах и информационных системах.

Примеры бизнес-анализа включают:

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

Роли бизнес-аналитиков

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

Стратег

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

Архитектор

Иногда организациям необходимо ввести изменение, чтобы решить деловые проблемы, найденные стратегическим аналитиком, упомянутым выше. Бизнес-аналитики анализируют цели, процессы и ресурсы, и предлагают пути, которыми могла быть сделана модернизация (реорганизация бизнес-процессов), или усовершенствования (модернизация бизнес-процессов). Специфические навыки этого типа аналитика — это навыки, такие как знание бизнеса, разработки требований, анализа заинтересованных лиц и моделирование бизнес-процесса. Хотя роль требует понимания технологий и их использования, это не IT-роль.

Три элемента являются основными для этого аспекта бизнес-анализа: модернизация основных бизнес-процессов; подключений технологий для поддержки основных процессов; и управление организационными изменениями. Этот аспект бизнес-анализа также называют «усовершенствованием бизнес-процесса» (модернизация бизнес-процессов).

Системный аналитик

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

Цели бизнес-аналитиков

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

  • Уменьшить затраты
  • Найти решение проблемы
  • Закончить проекты вовремя
  • Улучшить эффективность
  • Задокументировать верные требования

Уменьшить затраты и закончить проекты вовремя

Задержки проектов довольно дорогостоящие.

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

N.B. На многих проектах (особенно больших) за своевременное завершение проекта отвечает менеджер проекта. Задание бизнес-аналитика состоит больше в том, чтобы гарантировать, что, если проект не закончен вовремя, тогда, по крайней мере, самые приоритетные требования выполнены.

Задокументировать верные требования

Бизнес-аналитики хотят быть уверенными, что они описывают приложения, которые удовлетворяют потребностям конечных пользователей. По существу, они хотят описать правильное приложение. Это означает, что они должны задокументировать правильные требования, внимательно слушая отзывы клиентов, и предоставить полный набор ясных требований техническим архитекторам и инженерам, которые напишут программу. Если бизнес-аналитик имеет ограниченные средства или навыки для выявления верных требований, то высока вероятность того, что он задокументирует бесполезные или неверные требования. Время, потраченное на документирование ненужных требований, влияет не только на бизнес-аналитика, но и также влияет на весь процесс разработки. Инженеры должны создавать код программы, чтобы выполнить эти ненужные требования, и тестеры должны удостовериться, что запрошенные требования действительно работают, как описано в документации. Эксперты оценивают, что от 10 до 40 % требований в новых приложениях являются ненужными или остаются неиспользованными. Сокращение количества этих ненужных требований даже на одну треть может привести к существенному снижению затрат.

Улучшить эффективность проектов

Эффективность может быть достигнута двумя способами: сокращением переделок готовых частей и сокращением продолжительности проекта.

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

Сокращение продолжительности проекта представляет две потенциальных выгоды. Ресурсы, освобождённые за каждый месяц, на который был сокращён проект, могут быть использованы на других проектах. Это может привести к сбережениям на текущем проекте и к более ранним стартам новых проектов (таким образом увеличивающим потенциальный доход).

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

См. также

Примечания

  1. ↑ Бариленко В. И. Бизнес-анализ как важный вид консалтинговых услуг // РИСК: Ресурсы, Информация, Снабжение, Конкуренция. — № 4. — 2012. — С.202-207.

Литература

  • Конрад Карлберг. Бизнес-анализ с использованием Excel. Решение бизнес-задач, 4-е издание = Business Analysis: Microsoft Excel. — М.: «Вильямс», 2013. — 576 с. — ISBN 978-5-8459-1888-8.

ru-wiki.org

Маркетинговое исследование до начала своего дела

маркетинговое исследование до начала своего дела

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

 

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

 

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

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

Примеры проведения маркетингового исследования до начала своего дела на «бытовом уровне»

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

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

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

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

Маркетинговое исследование нужно проводить ДО начала действий по открытию своего бизнеса.

Маркетинговое исследование должно предварять каждый новый шаг в бизнесе

Именно поэтому крупные корпорации держат в своем штате целые маркетинговые подразделения или тратят деньги на заказ исследований специализированным фирмам. Эти затраты впоследствии экономят огромные деньги при производстве и организации продаж.

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

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

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

Маркетинговое исследование до начала. Маркетинговое исследование до начала

Удачи вам в бизнесе!

Маркетинговое исследование до начала. Маркетинговое исследование до начала

www.b-i-plan.ru

Бизнес-исследование Deloitte: фокус на работе в команде

Источник картинки: LinkedIn

В марте Дмитрий Шаменков провел вебинар «Принципы высокоэффективных команд», в котором упомянул статью Джоша Берсина, опубликованную на сайте Forbes.com, «New Research Shows Why Focus On Teams, Not Just Leaders, Is Key To Business Performance» по исследованию Deloitte 2016 года. Представляем вашему вниманию фрагмент этой статьи на русском языке.

Перевод Я. Коршак.

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

 Делойт недавно опубликовал новое исследование основных задач в бизнесе — Deloitte Human Capital Trends 2016 — результаты которого оказались поразительными. Среди более семи тысяч интервьюированных компаний (из около ста тридцати стран), вопросом номер один, занимающим умы руководителей, оказался: «Как реконструировать организационную модель компании, чтоб отвечать всем требованиям трудовых ресурсов и бизнес-климата, в соответствии с сегодняшним днем?». После практически года исследований, стало ясно, что современное цифровое устройство делового мира сотрясает фундамент классической структуры организации компаний, смещая фокус внимания с традиционной должностной иерархии на принцип командных сетей, как их обозначил Делойт. Новый вид организации рабочего процесса стимулирует нас изменить привычные должностные сценарии и обязанности, пересмотреть существующие модели карьерного роста и внутреннюю мобильность компании, обратить особое внимание на навыки и обучение персонала в качестве ключа к успеху, перестроить процессы целеполагания и поощрения, по-другому взглянуть на роль лидера.

 Исследование, обозначившее топ десять важнейших мировых тенденций на 2016 год, показало, что большинство вопросов, с которыми сталкиваются компании на сегодняшний день (наем рабочих, подбор кадров, культура, торговые отношения, внедрение инноваций), неразрывно связано с новым, командным способом рабочей организации. Таким образом, 92 % опрошенных Делойтом компаний провозглашают одной из ключевых задач сегодня «редизайн» рабочих процессов и ставят эту тенденцию на первое место.

 Что такое «Командная Сеть» и почему именно сейчас?

 Если взглянуть на исследование, можно обнаружить компании, которые уже действуют таким образом. Лишь 24% крупных компаний (>5000 служащих) и 38% от числа всех компаний, участвовавших в исследовании, нуждаются в сохранении привычной должностной иерархии. Мы, натурально, начинаем управлять нашим бизнесом посредством формирования команд по продажам, розничных магазинов, сервисных бригад, проводя географически независимые операции.

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

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

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

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

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

  1. Общие ценности и культура.

Так как люди работают в командах, разбросанных по миру в максимальной близости к заказчику, им требуется выработать общие руководящие установки и систему ценностей, а так же приемлемый режим,  чтобы иметь возможность грамотно принимать решения. Эта необходимость проистекает из миссии, культуры, и выливается в острую необходимость во взаимопонимании, чувстве меры и выверенной системе ценностей (86% компаний считают это важным). Тренд, названный «Формируй Культуру, Управляй Стратегией» и статья » Why Culture is the Hottest Trend in Business Today» детально описывает эти процессы.

  1. Прозрачность целей и проектов.

Люди, работающие друг с другом в небольших группах и командах,  должны взаимодействовать друг с другом и на общекомандном уровне, и это невозможно без ясности поставленных целей, хорошо проработанных финансовых задач и осведомленности всех членов команд о том, над чем в данный момент работают остальные. Это подробно описывают исследования «Next Generation Performance Management» и » The End of the Bell Curve».

  1. Обратная связь и свободный поток информации.

В условиях командной работы и взаимодействия компаний с заказчиками, нам необходимо делиться информацией о том, что работает, что не работает, что продает, и какие проблемы должны решаться. Пока локальное руководство и лидеры команд (имеются в виду управляющие отделами, менеджеры по продажам) вынуждены брать на себя ответственность за ошибки, все остальные должны знать, какие имеют место проблемы, чтоб иметь возможность поддерживать команду. Это происходит сегодня в аналитических и информационных центрах, в системах со свободным обменом обратной связью, и вытесняет необходимость в классических годовых отчетах об эффективности. Принятие решений требует фокусировки на открытой и прозрачной обратной связи и взращивании ясной инклюзивной культуры.  Более подробно в исследованиях «Why Inclusion is A Critical Business Strategy in 2016″ и » Feedback is the Killer App».

  1. Поощрение людей за навыки и вклад, а не на основании занимаемой должности.

В конечном итоге, при работе в командных сетях, работники вознаграждаются не на основании занимаемой позиции, а на основании их вклада. Дни лидерской должностной иерархии («Я — начальник, делай, что я говорю») прошли. На ее месте возникает новый тип карьеры, основанный на навыках, общности системы ценностей, последовательности и вкладе в компанию в целом.  Глава » Leadership Awakened: Generations, Teams, Science» рассказывает об открытиях в этой области.

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

Исследование «Топ 10 выявленных трендов».

Название «Новая Организация: Другое Устройство» проистекает из детального изучения глобальных тенденций.  Делойт проводит это исследование уже четвертый год и, на данный момент, количество опрошенных уже перевалило за 7000 из более 130 стран. Анализ и сортировка полученных данных проводятся в соответствии с индустрией, размерами компаний, их географическим положением, и показывают, что обнаруженные тенденции затрагивают компании разной величины по всему миру.

Касательно структуры, исследование обнаружило, что только 26% крупных компаний (>5000 сотрудников) организованы сегодня по принципу должностной иерархии (отделы продаж, управления рынком, финансовые структуры, отделы обслуживания и разработки, etc.), в то время, как 82% компаний уже реорганизованы, пребывают в процессе реорганизации, либо планируют это, чтобы лучше соответствовать всем требованиям заказчика. Вопрос структурирования, как мы уже знаем, находится на стадии динамичного развития: только 8% среди опрошенных компаний уверены, что их структура полностью оптимизирована, и 4% не планируют никаких изменений.  Посредством общения с представителями компаний и изучения этого вопроса, Делойт выявил, что двигательными механизмами этого тренда являются цифровые технологии, прозрачность информации, демографические процессы и слом устаревших основ бизнеса.

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

Многие из нас помнят старомодные организационные матрицы, популярные в 80-х годах. Сегодняшние же матрицы, повторимся (Я. К.), делают работу в компании похожей на голливудское кино, где люди со своими навыками, знаниями и опытом, собираются в команду и работают над определенным проектом и, по мере обучения и адаптации в компании, они, со временем, переходят в следующие проекты.

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

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

shamenkov.ru

навыки бизнес-аналитика | Бизнес-Анализ в России

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

Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:

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

Функциональные требования — это требования к системе.Бизнес-требования — эквивалентно бизнес-целям.Между ними — Пользовательские требования, User Requirements.Пользовательские требования формулируются в терминах предметной области, а функциональные требования — в терминах системы.

Бизнес-процессы — самое начало работы.Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):1. Бизнес-моделирование2. Выявление требований3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн4. Реализация5. Тестирование6. Опытно-промышленная эксплуатация7. Support и развитие системы

Совсем упрощенно:1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

Типовая структура требований выглядит как «Система должна … /утверждение о необходимом функциональном поведении системы/» или «система должна позволять … /утверждение о возможности, предоставляемой пользователю или внешней системе/.

Например:«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

Пример различий между пользовательскими и функциональными требованиями:Пользовательское: «Система должна выводить отчеты на печать»Функциональное: «Система должна обеспечивать вывод отчетов на печать, обеспечивать возможность выбора и настройки локального или сетевого принтера, выбора ориентации бумаги».

Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM, TelelogicDoors, Rational RequisitePro) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

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

Схема процесса разработки с уровнями требований

requirement_management

Формирование и анализ требований

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

Аттестация требований

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

Подготовка к интервью по сбору требований у заказчика

interview_requirements

Компания — Бизнес-требования

Источники: Топ-менеджмент компанииДокумент: Бизнес-требования (обоснование потребностей инициативы)Ответственный: Менеджер проекта

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

  1. Описание контекста и списка ключевых заинтересованных лиц
  2. Описание целей создания системы и критериев достижения
  3. Ключевые бизнес-требования к решению и их приоритеты
  4. Существующие и возможные ограничения на решение

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

Заказчик — Документ требований заинтересованных лиц

Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:

  • Бизнес-назначение
  • Бизнес-рамки
  • Обзор бизнеса
  • Заинтересованные лица
  • Организационная среда
  • Цели и результаты
  • Бизнес-модель
  • Информационная среда
  • Бизнес-процессы
  • Политики и правила
  • Ограничения деятельности
  • Организационная структура
  • Концепция использования системы
  • Сценарии эксплуатации
  • Проектные ограничения

Пользователь — Требования пользователя

Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.Источники: ПользовательДокумент: Пользовательские требования/Требования к ПООтветственный: Системный аналитик

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

Проблемы при формировании пользовательских требований

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

Системные требования

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

Функциональные требования

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

Стандартные формы для специфицирования функциональных требований:

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

Нефункциональных требований

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

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

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:

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

Требования предметной области

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

Требования к продукту

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

Организационные требования

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

Требования к интеграции

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

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.Основными функциями ESB являются:

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

Интеграция точка-точка

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

Интеграция данных

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

Задачи интеграции данных:

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

Интеграция ETLИнтеграция ETL характеризуется следующим сценарием:На платформе ETL пишется процесс, который1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы3) Загружает данные в таблицы БД 2й системы.

Файловый обменФайловый обмен характеризуется следующим сценарием:1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле.2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем)3) Приложение которому нужны данные, загружает подготовленный файл.

Требования к пользовательскому интерфейсу

Пользовательский интерфейс — часть программной системы. Требования к пользовательскому интерфейсу могут быть разбиты на две группы:

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

К первой группе можно отнести следующие типы требований:

  • Требования к размещению элементов управления на экранных формах
  • Требования к содержанию и оформлению выводимых сообщений
  • Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

  • Требования к реакции системы на ввод пользователя
  • Требования к времени отклика на команды пользователя

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

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

Классификация изменяемых требований

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

Процесс управления изменениями

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

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

Как и у всех путешествий, у проекта улучшения процессов должна быть цель. Если не определить конкретных целей по улучшению, люди не смогут работать согласованней, а вы не сможете сказать, есть ли движение вперед, не сможете определять приоритеты задач и сказать, когда цель достигнута.Метрика — измеримая характеристика проекта, продукта или процесса.Ключевые показатели производительности (KPI) — это метрики, привязанные цели и служащие мерилом продвижения проекта к достижению определенной цели или результата. Набор KPI-показателей может отображаться на контрольной панели, показывая приближение к целям.

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

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

  • Правильно ли были проанализированы проблемы и выявлены их первопричины?
  • Выбрали ли вы действия по улучшению, непосредственно направленные на эти первопричины?
  • Был ли реалистичным план реализации этих действий по улучшению? Был ли план реализован, как планировалось?
  • Изменилось ли что-то со времени исходного анализа, что должно было заставить переориентировать действия команды по улучшению?
  • Действительно ли члены команды приняли новые приемы работы и прошли период обучения, чтобы начать активно применять их на практике?
  • Были ли поставлены реалистичные цели, которые команда была в состоянии достичь?

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.requirements_management_process_documents

Документы процесса разработки требований

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

Документы процесса управления требованиями

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

Пример дорожной карты совершенствования процессов работы с требованиями

roadmap_process_improvement_work_requirements

iiba.ru

Исследование бизнес процессов - изучение документации

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

Изучение документации состоит из 3-х основных этапов:

1. Получение документов2. Обработка документов3. Анализ документов

Получение документов

Понятное дело, что для того чтобы получить документы, их нужно для начала запросить. Но формулировка вопроса как — «Дайте мне пожалуйста все документы по процессу», вряд ли найдет понимание. Поэтому формулировка запроса важна. Запрос — это конечно условное понятие. Можно «запросить» документы письменно, а можно и устно. Но в любом случае, вы должны дать пояснение — какие конкретно документы вам необходимы. Несмотря на то, что набор документов отличается от компании к компании, он имеет определенную структуру и общие понятия.

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

Классификация документов

1. Управляющие документы

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

2. Документы процесса

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

Важно. Вабще, понятие документ, не означает наличие отдельной «бумажки». Запись в журнале это документ. Электронная заявка или форма это тоже документ. Даже электронное письмо является документом, с точки зрения управления бизнес процессами. Иными словами, документ это информация, имеющая определенную форму — бумажную, электронную, жидкую, газообразную или любую иную… шучу))

3. Функциональные документы

  • должностные инструкции — содержат в себе описание прав и функциональных обязанностей сотрудников, которые можно отнести к бизнес процессам.
  • политика, положение — документы общей направленности, тем не менее из них можно почерпнуть полезную информацию. К примеру, если вы занимаетесь процессом «Управление качеством», то вам может понадобится «Политика качества» и / или «Положение о отделе контроля качеством»

4. Документы, отражающие определенные показатели процесса

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

Обработка документов

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

Распределение документов по процессамРаспределение документов по процессам

Следующее. Нужно просмотреть документы и обозначить взаимосвязи между ними. Взаимосвязь между документами — когда в одном документе есть прямая или косвенная ссылка на другой документ. С прямыми ссылками все понятно. Косвенная слыка, это когда документ подразумевается, но не указывается конкретно. К примеру, не редко можно встретить формулировку «Указанное в соответственном положении». «Соответственное положение» и есть косвенная ссылка. Структура документов должна приобрести приблизительно следующий вид:

Взаимосвязи документовВзаимосвязи документов

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

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

  • Кто участвует в процессе?
  • Что каждый участник делает в процессе?
  • Какие конкретно операции выполняет и в каком порядке?
  • С чего начинается процесс?
  • Каков результат процесса?
  • Что используется для реализации процесса и в каком количестве? — инструменты, программы, расходные материалы, деньги и другие ресурсы.
  • Какие документы использует процесс?
  • Какие документы появляются в процессе?
  • Кто использует продукты процесса?
  • От кого зависит начало и выполнение процесса?
  • Какие показатели отслеживаются?
  • Кто и каким образом управляет процессом?

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

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

Пример обработки и структурирования документаПример обработки и структурирования документа

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

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

Инвестиции в будущую экономию времени всегда окупаются.

Анализ документов

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

  1. Структура документов
  2. Выжимка информации и заметки к ним.
  3. Модель бизнес процесса, созданная на оснвое информации из документов.

Отправной точкой для анализа является модель бизнес процесса.

Графическое представление хорошо как раз тем, что сразу дает представление о недостающей информацией. Скорее всего, модель, полученная на основе информации из документов, будет зиять логическими дырами. Это означает, что задав вопрос «А что происходит дальше?» применительно к участку процесса, вы не можете найти ответ в документах. К примеру, часто можно встретить такую формуировку — отправить отчет руководителю. Такая формулирвока наглядно демонстрирует «логическую дыру». Не понятно каким образом отправить, когда, какому именно руководителю и, что самое вжное, что происходит после этого.

Итак, первым шагом является анализ модли бизнес процесса на предмет логических разрывов.Логический разрыв — это когда вы не можете найти ответ на вопрос «Что происходит дальше».Каждый разрыв необходимо записать и пометить к какому участку, подпроцессу или процедуре он относится.

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

Далее. Участники процесса. Нужно проверить, кто выполняет те или иные операции процесса. В модели бизнес процесса, не может быть подпроцессов или операций, которые как бы выполняются, но непонятно кем. На деле такое встречается повсеместно.

Документы процесса. Относительно каждого документа процесса необходимо выяснить:

  • Откуда данный документ появляется?
  • Что и кто с ним делает в процессе?
  • Как документ изменяется, какая информация вносится или используется из него?
  • Что происходит с документом когда он выполнил свою функцию?

Если вы не можете найти ответы на данные вопросы, запишите их и проясните в дальнейшем.

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

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

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

После тщательной обработки документации можно приступать к следующему этапу — проведение интервью.

[maxbutton id=»1″] [maxbutton id=»2″]

rzbpm.ru