Системный анализ бизнес плана

Системный экономический анализ: значение и этапы при составлении бизнес-плана

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

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

Системный экономический анализ является основой бизнес-плана (стратегического плана развития, плана реструктуризации, инвестиционного проекта и т.п.) и разделяется на три этапа. [4]

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

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

Третий этап — выбор вариантов развития предприятия. В соответствии с выбранной стратегией поведения предприятия на рынке определяется взаимоувязанная система, состоящая из: снабженческой и сбытовой политики (выбор маркетинговой стратегии и тактики, мониторинг оперативной информации о рынке и т.д.) производственно-технологической и инновационной политики (минимизация затрат на производство и реализацию продукции, улучшение качества продукции и др.) ценовой политики; финансовой политики; инвестиционной политики кадровой политики [2]

Итак, необходимость в выработке новой стратегии, а значит и в системном и комплексном экономическом анализе, возникает тогда, когда появляются новые цели или выясняется невозможность достижения ранее определенных целей с помощью прежней стратегии Комплексный подход, прежде всего, означает проведение анализа отдельных экономических показателей во взаимосвязи и взаимозависимости, в тесной связи с общим уровнем экономического, организационного, технического и технологического развития производства, уровнем социального развития коллектива предприятия. Сущность этой концепции заключена в ответе на вопрос «Как следует осуществлять управление организацией в условиях динамичной, изменчивой и неопределенной среды?»[3].Ответ на поставленный вопрос включает не только необходимость проведения анализа и оценки среды и прогнозирования того, как она будет изменяться во времени, но и создания такой системы управления, которая бы постоянно поддерживала соответствие между средой и характером и результатами деятельности организации.

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

Литература: Журнал «Экономический анализ:теория и практика»12(177),2010 апрель Пястолов С. М. Экономический анализ деятельности предприятий: учеб. пособие для вузов / С. М. Пястолов. М. : Академический Проект, 2006. 572 с. (Gaudeamus) (Учебное пособие для вузов). Н.П. Любушин «Экономический анализ», 308 с., 2007 иляровская Л.Т. «Комплексный экономический анализ хозяйственной деятельности предприятия», 360 c., 2008

Источник

Бизнес-анализ для чайников: зачем вам это надо?

Зачем вам нужен бизнес-анализ и из чего он состоит? Разбираем топ основных вопросов новичков.

Что такое бизнес-анализ?

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

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

Бизнес-анализ включает в себя несколько разделов:

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

Прокачайтесь из бухгалтера в бизнес-аналитика. Директора платят больше универсальным специалистам, которые умеют выявлять потребности бизнеса. Записывайтесь на факультет системной и и бизнес-аналитики Онлайн-университета GeekBrains от Mail.Ru Group. После обучения они гарантируют трудоустройство.

Как это работает?

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

Для расчета можно использовать такой показатель, как добавленная стоимость человеческого капитала (HCVA — human capital value added). Этот показатель помогает определить реальное влияние персонала на прибыль.

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

Предположим, компания зарабатывала 120 миллионов рублей в квартал

Все расходы компании, при этом составили 96 миллионов рублей. Стоимость рабочей силы составила 39 миллионов рублей. Из них 30 миллионов рублей — оплата труда, 9 миллионов — страховые выплаты) . Количество сотрудников — 760 человек.

HCVA = (120 000 000 -(96 000 000-39 000 000))/760= 82 894,74 рубля.

Доходы предприятия после пандемии упали на 35%. То есть доход составил 78 миллионов рублей. Расходы падали более низкими темпами и составили 67,2 миллионов рублей. При этом собственник пытался сохранить численность персонала. Премии и выплаты на оплату труда и соцстрахование сократились на 13 миллионов и составили 26 миллионов рублей. Из них 20 миллионов — оплата труда, 6 миллионов — выплаты на социальное страхование.

Как же изменилась при этом добавленная стоимость человеческого капитала?

HCVA = (78 000 000 -(67 200 000 — 26 000 000))/760= 48 421,05 рублей.

НСVA упала в 1,7 раза.

Следовательно, чтобы вернуться к прежнему уровню добавленной стоимости человеческого капитала, нужно сократить 316 человек и оставить только 444 человека.

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

Методов бизнес-анализа — великое множество. Среди самых известных — SWOT-анализ:

• Strengths (сильные стороны);
• Weaknesses (слабые стороны);
• Opportunities (возможности);
• Threats (угрозы).

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

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

С целью сокращения производственных расходов применяется ABC — метод. В группу А входят ресурсы, от использования которых компания получает наибольший доход (80%), в группу B — ресурсы, которые приносят средний доход 15%, в группу С — наименьший доход 5%.

Какие задачи решает бизнес-анализ?

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

Какие принципы лежат в основе?

Основу бизнес-анализа составляют его принципы:

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

Что мы получим в итоге?

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

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

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

Есть ли минусы?

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

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

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

• «Бизнес-анализ деятельности организаций», учебник под редакцией профессора Л.Н.Усенко,
• Бернард Марр, «Ключевые показатели эффективности. 75 показателей, которые должен знать каждый менеджер» ,
• Савчук В.П. «Управление финансами предприятия»,
• Л.С. Васильева, М.В. Петровская «Финансовый анализ»
• Н.Н.Соловьева, А.Ф.Ионова «Финансовый анализ. Управление финансами»

Бизнес-анализ лучше проводить самостоятельно или привлекать специалистов со стороны?

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

Источник

Бизнес и системный аналитик. Что нужно знать

Приветствую! Меня зовут Сергей, и я — бизнес/системный аналитик. В IT отрасли работаю около 8 лет, начиная с сопровождения, перетекающего в тестирование, и продолжая аналитикой: как бизнес, так и системной. Отдельно бизнес и отдельно системным аналитиком я ещё не работал.

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

Для кого, на мой взгляд, будет полезна статья:

• Начинающим бизнес / системным аналитикам;
• Аналитикам, желающим и дальше прокачивать свои проф. навыки;
• Возможно, менеджерам по подбору персонала.

Сразу скажу, что пункты ниже — это моё субъективное видение специализации аналитика, сформировавшееся в процессе практики. Если в вашей компании запущен полноценный scrum с product owner, сидящем в метре от вас, с выделенными для команды дизайнером и архитектором, что-то из перечисленного может оказаться невостребованным.

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

Бизнес аналитика

• Устраняйте двусмысленные требования на самых ранних этапах

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

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

Кейс из практики: месяц разработки был потрачен на функционал переноса списка активностей из объекта №1 в объект №2. На этапе приемочного тестирования обнаружилось, что заказчик ожидал совершенно иной функционал — копирование, а не перенос активностей. В процессе переделывания функционала и детализации двусмысленности IT-команда, во-первых, договорилась с заказчиком о MVP, а, во-вторых, о необходимости работы с корнем бизнес-проблемы. Было выдвинуто предположение, что сам функционал копирования требуется только лишь по причине недостаточно качественно реализованного функционала подгрузки шаблонов активностей.

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

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

• Требуйте у заказчика своего присутствия на бизнес-встречах

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

Во время очной встречи руководителя подразделения с подчиненным, где мы — аналитик и UX-дизайнер — сидели «в фоне», выявился целый ряд требований, который не проявлялся в течение целого года работы команды. Мы обращали внимание на все детали: ручные записи руководителя и сотрудника, на стикеры, на пометки в windows-блокноте, на действия внутри системы. По итогу такой встречи бэклог был существенно дополнен, а мы приступили к глубокой переделке реализованного в системе функционала.

• Старайтесь достигать соглашения и не формировать отписки

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

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

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

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

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

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

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

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

При необходимости (и отсутствия scrum) привлеките заказчика к такой встрече. Как правило, представители Бизнеса охотно соглашаются на такого рода инициативы.

• Научите заказчика отвечать на вопрос «Что?», а не формулировать требования в формате «Как»

Заказчик не должен формулировать бизнес / пользовательское требование с позиции «Как»: нам нужна кнопка на этом экране, чтобы сформировать отчёт; нам нужна ссылка на внешнюю систему в этом разделе; и так далее.

На этапе первичного анализа процесса, до непосредственно проектирования, заказчик не должен предлагать решение.

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

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

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

• Обязательно разделите пользователей на классы

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

Разделите пользователей системы на роли, а функционал, затачиваемый под одну роль, не «размазывайте» под другую роль.

Как-то раз в рамках Системы мы реализовали отображение списка сделок с клиентами.

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

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

Применяйте бэст-практики из UX: проработайте персонажей — модели пользователей. Убедите заказчика в необходимости разделять требования для каждого из персонажей.

• Активно применяйте аналитический мозговой штурм

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

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

• Если застряли в Waterfall, не отчаивайтесь и двигайтесь в сторону Scrum

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

• Ни в коем случае не демонизируйте заказчика

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

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

• Не перебивайте

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

Старайтесь и слушать собеседника, и слышать его.

• Избавьтесь от слов-паразитов

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

Системная аналитика

• При постановке задачи на front и back старайтесь описывать sequence диаграммы

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

Для быстрого «рисования» sequence диаграмм используйте плагин PlantUML для Confluence. Мне показалось, что быстрее набирать код, нежели ручками корректировать расположение блоков и стрелок. Но у каждого в этой части свой опыт и свои предпочтения.

• Освойте Swagger Editor

С точки зрения анализа Swagger Editor позволит вам закрывать ваши же дыры в требованиях. Где-то упустили атрибут, где-то забыли создать задачу в JIRA для доработки базы данных. Не пытайтесь зазубрить синтаксис Сваггера, а создайте шаблоны под разные типы API (справочники, фильтры и так далее), чтобы упростить себе жизнь в будущем.

• Активно используйте инструмент разработчика в целевом браузере, чтобы анализировать запросы клиента и ответы от сервера

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

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

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

Этот подход позволил нашей команде выводить достаточно хитрые доработки в пром в рамках спринтов без задержек.

В дополнение

• Погрузитесь в UX

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

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

Чтобы быть на одной волне, попрактикуйтесь в UX-анализе. Например, в свободное от работы время в Sketch или Figma, время от времени показывая результат вашему дизайнеру. Такой опыт аналитики никогда не будет лишним.

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

Источник