Бизнес процесс мониторинга бизнес плана
Приветствую всех читателей! Сегодня хотелось бы поговорить об основных принципах мониторинга бизнес-приложений, которые ежедневно используют многие компании по всему миру. Само понятие «бизнес-приложение» следует понимать как программный комплекс, который обеспечивает поддержку определенного бизнес-процесса компании.
Самый типичный пример архитектуры современного приложения — т.н. «трёхзвенка», т.е. веб-сервер, сервер приложений и сервер БД, следовательно, каждый из этих компонентов будет чуть менее чем полностью оказывает влияние на работу всего приложения. Если рассматривать именно такую конфигурацию, то со своего опыта могу сказать, что чаще всего возникает ситуация, которая в утрированном виде выглядит так:
Периоды недоступности или низкой производительности компонента проецируются на общую доступность приложения, которую ощущает на себе пользователь: т.е. даже при том, что нынешние прикладные системы могут обеспечивать свою доступность сильно за 90%, общая производительность всего бизнес-приложения может не дотягивать и до 90%. В реальном мире картинка выше может выглядеть как-то по-другому, но суть всегда одна — это непредсказуемость характера влияния мельчайших проблем с компонентами приложения на весь программный комплекс в целом. Ниже разбор что, как и почему, прошу под кат.
Сценарий, приближенный к реальному
В любой компании возникают ситуации, когда определенные периоды недоступности одного из звеньев приложения в итоге выливаются в периоды низкой производительности либо полной недоступности пользовательского веб-интерфейса (читай, основного функционала приложения). Если ИТ-ландшафт компании сложный, то бывает весьма затруднительно разобраться, какой именно слой является источником проблемы и к кому обращаться за ее решением. Если вернуться к визуализации такой штуки, то это все можно изобразить следующим образом:
Получается ситуация lose-lose, т.е. проигрывают все. Пользователи чувствуют, что ИТ их не понимает, линейный руководитель для решения конкретной ситуации задействует ИТ и самого главного босса, который посылает лучи негодования ИТ-менеджеру. ИТ-менеджер в смешанных чувствах идет к своим администраторам, которые пытаются валить друг на друга, предоставляя результаты своих систем мониторинга (или работы самописных скриптов) и далее, далее, далее. В общем-то такая ситуация может длиться довольно долго, до тех пор пока проблема в лучшем случае самоустранится, либо все ИТ-администраторы придут к соглашению проводить диагностику каждый в своей системе и наконец найти корневую причину. По опыту коммуникаций с заказчиком могу сказать, что бывает еще такой сценарий, когда своими силами сделать ничего не удалось (в силу недостаточной экспертизы или других объективных причин), и заводится кейс у вендора соответствующего софта, что может растянуться уж совсем на неопределенный срок.
Есть еще момент, на котором остановлюсь подробнее. Любая прикладная система требует мониторинга, и не всегда в компании есть для этого нечто промышленное. В такой ситуации администратора в большинстве случаев выручит встроенный механизм мониторинга приклада, а в случае его отсутствия это может быть некий хорошо зарекомендовавший себя скрипт, запускаемый на регулярной основе. Отлично, что администратор использует удобные и понятные для него инструменты, а теперь допустим, что возник ахтунг планетарного масштаба (радикальное снижение производительности приложения или его полная недоступность). При этом механизм запуска скрипта решил какое-то время не исполняться и спокойно покурить в сторонке. В итоге размахивать перед ИТ-директором скриншотами, подтверждающими, что мониторинг всё-таки был, но вот скрипт выдал exception и scheduler споткнулся, может быть не лучшей идеей. Встроенный мониторинг хорош тем, что учитывает особенности приложения, но опять-таки владельцу приложения может быть не очень удобно собирать разнородную информацию со всех администраторов и отчитываться перед руководством о непрерывности бизнес-процесса, который поддерживает приложение. По моему мнению, администраторы прикладных систем не должны тратить свое драгоценное время на поддержку системы мониторинга, им стоит переложить этот функционал на специально обученных сотрудников внутри компании либо на внешнего подрядчика.
Как научиться понимать приложение
Что же можно сделать для формирования ситуаций win-win? Чтобы у больших боссов не возникало дополнительных вопросов на тему «а что вы делаете, чтобы такого больше не повторилось», и вы, как человек от ИТ (или менеджер по доступности такого-то сервиса), лишний раз не беспокоились, следует иметь оперативную информацию о состоянии всех компонентов систем, участвующих в основном (и не очень) бизнесе компании. Желательно на большом LCD-телевизоре, желательно с большими понятными подписями, цветовой индикацией (а-ля красный-жёлтый-зелёный) и, где-то рядом, списком фамилий напротив названий сервисов. А еще было бы здорово кликнуть мышью по сервису (который окрасился, например, в красный) и узнать, на каком звене возникла проблема. Таким образом, мы пришли к идее единой (а она может быть и зонтичной) системы мониторинга, которая охватывает все части бизнес-приложения, используя стандартные модули мониторинга (конечно, всегда есть возможность наравне со стандартными средствами использовать кастомные скрипты, либо вообще другую оупенсорсную или промышленную систему мониторинга). Ниже пример так называемого heat map, т.е. карты сервисов:
Таким образом, у сотрудников ИТ-подразделения или менеджера бизнес-сервиса есть возможность буквально «держать руку на пульсе» и в любой момент времени иметь представление о том, где возникла проблема, и у кого можно узнать о сроках решения, чтобы отчитаться перед пользователями или руководством. Очень полезен такой мониторинг бывает, когда вы проводите регламентные работы на большом количестве приложений (или их компонент) и хотите убедиться, что всё успешно восстановилось после перезагрузки, ведь тратить остаток ночи (ну, ведь правда, такие работы чаще всего проводятся по ночам) на ручную проверку всего «зоопарка» было бы не совсем рационально.
Нынешний уровень промышленных систем мониторинга позволяет производить глубокий контроль и даже рассчитывать уровень доступности бизнес-приложения. Особенно важным это может быть, когда ИТ-департамент предоставляет бизнесу набор услуг (или сервисов), по которым заключено соглашение об уровне обслуживания (SLA). Система мониторинга позволит формировать отчеты с необходимой детализацией, позволит накапливать статистику и понимать, какие компоненты бизнес-приложения недостаточно производительны, и, в конце концов, позволит бизнесу хотя бы как-то понимать, насколько качественно предоставлен ИТ-сервис. Но наиболее полное представление о работе приложения вы будете иметь, если с определенной периодичностью на среднестатистической рабочей станции будете делать то, что делает пользователь. Об этом ниже.
Как научиться понимать пользователя
Наконец, переходим к вопросу мониторинга бизнес-приложения с точки зрения пользователя, без этого вообще нынче никуда. Понятное дело, что конечные пользователи наиболее чувствительны к снижению производительности или недоступности приложения, и «видеть» их глазами было бы наиболее предпочтительным вариантом. Нанимать людей, которые будут, допустим, оформлять банковские проводки и сидеть с секундомером, замеряя время отклика веб-интерфейса того же Siebel, не самое лучшее занятие. Наиболее оптимальным вариантом в таком случае будет написание специального алгоритма (синтетической транзакции), который будет запускать браузер, производить авторизацию в приложении и перекидывать условную сумму в 1 рубль с одного счета на другой. Специально для дорогих читателей я написал браузерную транзакцию (есть еще транзакции с тяжёлыми клиентами) на примере одного известного интернет-магазина. По ней измеряется затраченное время на каждый шаг — первоначальная загрузка страницы в браузер, время на авторизацию пользователя, время на поиск товара и межстраничные редиректы и переходы – плюс проверяется успешное выполнение каждого шага и транзакции в целом.
Система позволяет контролировать, что загрузились конкретные изображения, также есть возможность распознавать текст со страницы (OCR-метод), сравнивать его с чем-нибудь или просто записывать, например, в БД. Можно получить тайминг транзакции, т.е. на каждом шаге запускается таймер, который измеряет время его выполнения и проверяет на успешность, чтобы владелец приложения мог понять, на каком шаге произошел сбой.
Получается, что если условный пользователь вам заявляет, что в вашем приложении все тормозит и глючит, вы сможете предоставить результаты таких транзакций и объяснить, что его случай уникальный и происходит в совершенном отрыве от реальности:) Если серьезно, то предоставление подобных графиков производительности поможем вам избавиться от ненужных активностей по поиску надуманных пользователем проблем.
В сухом остатке мы имеем инструмент, который позволяет получать информацию о наличии проблемы на самой ранней стадии (даже до начала обращения пользователей в службу поддержки). Успешность/неуспешность выполнения транзакции (или ее доступность) система мониторинга может позволять привязывать к бизнес-сервису (если говорить о сервисно-ресурсной модели) и настраивать степень ее влияния на сервис в целом (т.н. вес связи). Ниже пример сервисно-ресурсной модели:
Для тех, кто хочет еще больше понимать своих пользователей, существуют системы мониторинга реальных транзакций. Еще более круто, еще более технологично. Выглядят такие системы следующим образом:
Т.е. весь HTTP/HTTPS трафик, который маршрутизирован на веб-сервер (ферму веб-серверов), зеркалируется на специальный коллектор (на схеме обозначен как Collector). Далее происходит его анализ и формирование заранее заданных представлений (иногда называются дашлетами от англ. dashlets). Такого рода мониторинг можно использовать, например, как механизм отладки веб-приложений для поиска низкопроизводительных компонент, либо определения алгоритмов перехода пользователя между страницами, определения географической локации пользователя, типа браузера и т.п. Ниже приведен пример дашборда анализатора сетевого трафика:
Обратите внимание на т.н. «стакан» в верхнем правом углу окна. Это заранее заданный алгоритм перехода пользователей между страницами, который подсчитывает, сколько пользователей переходят от одной страницы к другой именно в таком порядке, и сколько пользователей выходят из этой последовательности и на каком шаге. Строить графики и делать отчеты можно практически по любому параметру, который передается в HTTP заголовках (имя пользователя, его id и т.п.), т.е. система действительно гибкая и готова подстраиваться под потребности заказчика.
Наконец, переходим к глубокой диагностике бизнес-приложения (особенно актуально для заказных разработок). Такого рода анализ могут делать системы типа Application Diagnostics, диагностику можно производить как для JAVA, так и для .NET приложений. Специальный агент прицепляется к процессу, который выполняется на сервере и анализирует последовательность его действий. Например, на картинке ниже приведен пример такого анализа для .NET приложения, которое выдает exception, и мы можем видеть, что он возникает после запроса в БД.
Для отладки и мониторинга самописных приложений просто must have.
А что же на выходе
На выходе мы можем иметь зонтичное решение, которое будет получать данные о работе приложения из всех описанных источников и, что самое главное, полную картину того, что происходит внутри приложения, и как это отражается на нашем (не побоюсь этого слова) любимом пользователе, ради которого всё и затевается. На рынке немало софтверных вендоров, которые имеют весь арсенал описанных решений, и выбрать для себя оптимальное решение, исходя из бюджета, потребностей, ожиданий и т.п., может быть не так уж и сложно. Б̀о́льшую часть оупенсорсных и промышленных решений можно собирать как пазл: т.е. если у вас уже есть сетевой или инфраструктурный мониторинг от одного вендора, вы с большой долей вероятности сможете дополнить его, например, синтетическим мониторингом от другого вендора.
На сегодняшний день ИТ стремится приблизиться к бизнесу настолько, насколько это возможно, и оказывать влияние на стратегию компании в целом, а инструменты, в которые может заглянуть руководитель ИТ (или выше) и понять, что деньги потрачены не зря, в целом очень востребованы рынком.
Я попытался дать поверхностное представление о различных методах мониторинга абстрактного бизнес-приложения, и если у вас возникли вопросы, то с радостью на них отвечу. Будет также интересно узнать, какими способами вы решаете задачи мониторинга, и с какими проблемами приходится сталкиваться, особенно с учетом влияния нынешних внешнеполитических факторов. Спасибо за внимание!
Автор статьи: Антон Касимов
Источник
Основной целью разработки бизнес-плана является планирование хозяйственной деятельности предприятия в соответствии с потребностями рынка. Бизнес-план — это подробный, четко структурированный и тщательно подготовленный документ, описывающий цели фирмы, средства их достижения и прогнозируемое состояние фирмы. Это удобная, общепринятая форма ознакомления потенциальных инвесторов с проектом, в котором им предлагается принять участие.
Существуют две важнейшие причины для подготовки бизнес-плана. Необходимо:
¦ убедить инвесторов в целесообразности вложения средств в бизнес или предоставления кредита;
¦ помочь сохранить бизнес и не позволить случайным обстоятельствам отрицательно повлиять на результаты деятельности.
Основная цель бизнес-плана — достижение разумного и выполнимого компромисса между тем, что фирма хочет и чего может достичь. План призван показать работникам и потенциальным инвесторам целостность предлагаемой стратегии. Бизнес-план должен ответить на три ключевых вопроса:
1) где сейчас находится компания (текущее состояние бизнеса);
2) в каком направлении развивается бизнес (желаемое состояние бизнеса);
3) каким образом будут достигнуты поставленные цели (наиболее эффективный путь достижения желаемых результатов).
Модель бизнес-плана определяется его принадлежностью к to,v или иному типу и особенностями предприятия, для которого он разрабатывается. В общем виде, согласно существующим рекомендациям, бизнес-план должен состоять из разделов, приведенных ниже.
1. Возможности фирмы (резюме).
2. Виды товаров (услуг).
3. Рынки сбыта товаров (услуг).
4. Конкуренция на рынках сбыта.
5. План маркетинга.
6. План производства.
7. Организационный план.
8. Правовое обеспечение деятельности.
9. Оценка риска и страхование.
10. Финансовый план.
11. Финансовая стратегия.
В первом разделе бизнес-плана должно быть представлено резюме, которое фактически является предельно сокращенным рефератом, своего рода уведомлением о сути плана, намерениях фирмы. Однако по содержанию оно несколько отличается, если для вновь начинающегося бизнеса требуются значительные внешние инвестиции. В этом случае резюме должно убедить будущего инвестора в серьезности и выгодности намерений фирмы, а также заставить его подробнее познакомиться с планом.
При планировании действующего бизнеса резюме должно отразить основные изменения в деятельности предприятия: его экономический рост, увеличение объемов деятельности, повышение качества, прибыльности и т.п.
Второй раздел бизнес-плана посвящен обоснованию целесообразности выпуска нового вида продукта или услуги. В нем приводят описание технического уровня продукции в целом, основных качественных параметров и уникальных свойств, недостатков и возможностей модификации; дают сопоставление продукции с имеющимися и предполагаемыми к выпуску аналогами. При этом продукцию производственного назначения рассматривают с точки зрения ее назначения, возможных сфер использования, экологичности, безопасности и удобства для обслуживания.
Кроме того, в этом разделе приводят сведения о наличии у продукции различного рода сертификатов, защищенности ее патентами, лицензиями, товарными знаками, как в стране, так и за рубежом. На основании перечисленных и иных сведений делают вывод о привлекательности продукции в целом и по сравнению с важнейшими конкурентными образцами.
В заключение рассматривают жизненный цикл продукции, время, необходимое для ее освоения и запуска в производство, возможности выпуска побочной продукции из отходов и необходимые для этого дополнительные капитальные вложения, научно-исследовательские работы и опытно-конструкторские разработки.
В третьем разделе оценивают рыночные возможности бизнеса, формируют реалистическую оценку состояния конкуренции, сильных и слабых сторон фирмы по сравнению с другими предприятиями.
Анализ внешней среды необходим для принятия верных управленческих решений. Обычно процесс исследования рынка включает в себя:
¦ анализ конкуренции на рынке;
¦ основные характеристики потребителей;
¦ оценку тенденций изменения рынка;
¦ организацию сбыта.
Используя данные анализа, освещают следующие вопросы:
¦ потенциальные потребители продукции (фирмы, индивидуальные потребители), их территориальная принадлежность, численность будущих клиентов, мотивы покупок;
¦ особенности сегмента рынка, на который ориентируется фирма (степень удовлетворения потребностей, демографические особенности, географические границы, тенденции развития);
¦ емкость рынка и перспективы его развития;
¦ характер спроса — постоянный, сезонный, циклический; и характеристика конкурентов;
¦ конкурентные преимущества фирмы;
¦ барьеры входа на рынок (нехватка средств, времени, технологические ограничения, инерция спроса, высокая себестоимость, отсутствие сбытовой сети и т.д.).
В четвертом разделе может быть дана оценка конкурентоспособности продукции, путей борьбы с основными конкурентами и завоевания рыночной доли. При этом в качестве конкурентов рассматривают не только реальных, но и потенциальных соперников.
В этом разделе приводят общее число конкурирующих фирм и перечисляют наиболее крупные с указанием контролируемой ими Доли рынка; характеризуют основные параметры, по которым может вестись конкурентная борьба.
В пятом разделе описывают основные составляющие маркетинга: ценообразование, сбыт, система продвижения товара на рынке. Цель — показать стратегию маркетинга, которая позволит выйти на Уровень продаж и прибыли, определенный в финансовом плане. В разделе также рассматривают:
¦ подход к системе ценообразования — предполагаемая система скидок, анализ уровня цен на продукцию в динамике;
¦ организацию сбыта продукции и каналы сбыта;
¦ систему продвижения товаров на рынке — примерный объем затрат, организация рекламы, стимулирующие мероприятия, паблисити;
¦ стратегию роста — выход на другие сегменты рынка, дифференциация продукции.
Стратегия маркетинга находит выражение в плане маркетинга элементами которого являются: краткая сводка его основных целей и положений; описание текущей маркетинговой ситуации (величина рынка, его основные сегменты, потребности покупателей, основные виды товаров, конкуренты, каналы распространения); опасности и возможности, открывающиеся в связи с реализацией товара; перечень задач и проблем; стратегии маркетинга; программа действий; затраты; способы контроля.
В шестом разделе целесообразно описать потребность в помещении, оборудовании и трудовых ресурсах, необходимых для достижения целей, а также систему снабжения. При этом желательно отразить:
¦ расположение помещений, потребность в ремонте;
¦ схему производственного процесса;
¦ состав и поставщиков необходимого оборудования, условия поставок, стоимость;
¦ сырье и материалы, их поставщиков, ориентировочные цены, норму запаса;
¦ наличие альтернативных источников снабжения сырьем и материалами;
¦ экологичность и техническую безопасность производства, контроль качества;
¦ требования в отношении трудовых ресурсов;
¦ возможности снижения прямых и накладных расходов;
¦ систему обслуживания и сервиса.
Седьмой раздел включает в себя организационный план. Он содержит информацию о персонале фирмы и структуре управления ею. Персонал характеризуется численностью, структурой, опытом, квалификацией, уровнем образования и т.п. По всем этим параметрам определяется потребность в кадрах на предстоящие 5 лет. В этом разделе излагают принципы подбора, оценки и продвижения кадров, политику в области заработной платы, льгот и поощрений на ближайшие 5 лет, а также дают описание существующей организационной структуры и системы управления организацией и направления их изменения связи с ее развитием; здесь же рассматривают вопросы внедрения методов управления.
Восьмой раздел посвящен правовым вопросам. В нем указывают:
¦ организационно-правовую форму бизнеса — по товариществам должны быть предоставлены условия создания и партнерства, по акционерным обществам — основные пайщики и принадлежащие им доли, число привилегированных и обыкновенных акций; приводится доля государственной собственности в уставном фонде;
¦ для акционерных обществ — состав совета директоров, краткие биографические справки, телефоны, степень вовлеченности в деятельность предприятия;
¦ для открытых акционерных обществ — число выпущенных акций, возможность дополнительной эмиссии;
¦ организационную структуру управления предприятием — команда управляющих, распределение обязанностей между ними, формы и условия оплаты труда;
¦ предполагаемые изменения в структуре управления в соответствии с требованиями проекта — планируемое пополнение команды менеджеров;
¦ заинтересованность местной администрации в проекте;
¦ консультантов, аудиторов фирмы.
В девятом разделе описывают условия, угрожающие деятельности предприятия, и пути снижения рисков. К основным типам рисков, возникающих в процессе хозяйственной деятельности, относятся риски уничтожения, порчи, хищения имущества, стихийных бедствий, политических конфликтов, финансовой и коммерческой неудачи. В этом разделе дают примерную оценку величины этих рисков и составляют список основных мероприятий, направленных на предотвращение ущерба или его компенсацию.
Десятый раздел содержит финансовый план, который включает в себя подготовку следующих документов:
¦ прогноз объема продаж;
¦ баланс денежных расходов и поступлений;
¦ таблицы доходов и затрат;
¦ сводный баланс активов и пассивов предприятия.
В одиннадцатом разделе, отражающем стратегию финансировали, обосновывают следующие показатели:
¦ потребность в финансовых средствах, метод расчета потребности, возможные источники получения средств;
¦ использование финансовых средств (капитальные вложения пополнение оборотных средств, выплата долга, приобретение другие фирм);
¦ долговременные финансовые стратегии (возможности изменения организационных форм бизнеса, изменение позиций учредителей, схемы погашения кредита);
¦ данные об аудиторской фирме, с которой сотрудничает предприятие.
Любой бизнес-план предоставляется конкретному заказчику и должен соответствовать его требованиям. Эти требования имеют свою специфику, поэтому не может быть универсального проекта и отсутствует его единая стандартная форма.
Для отечественных разработчиков бизнес-планов характерно недопонимание тех акцентов, которые нужно сделать, чтобы бизнес-план удовлетворил заказчика. Анализ показывает, что особое внимание уделяется рассмотрению финансов, эффективности проекта. В то же время мало анализируется рынок продукции и уровень ее конкурентоспособности. Часто переоцениваются рыночные потребности в будущей продукции из-за неудовлетворительного качества маркетинговых исследований.
Трудности во внедрении полноценного бизнес-планирования в России создает отсутствие реальной информации о конкурентоспособности продукции, конкурентной среде, конкурентных потенциалах. В российской практике бизнес-планирования необходимо, чтобы применительно к производству был тщательно спрогнозирован и в полной мере учтен вопрос уровня качества изделий или услуг.
Российская специфика состояния рынка усложняет процедуры разработки бизнес-планов и учета в них ряда труднопредсказуемых факторов. К последним можно отнести уровень инфляции, плавающие банковские и налоговые ставки, перевод рублевых показателей в твердую валюту, проблемы оплаты поставок из-за кризиса неплатежей, недостаточность информационных и статистических данных и т.д.
Мониторинг — это процесс выявления отклонений фактических показателей реализации бизнес-плана от их прогнозных значении и оценка влияния данных отклонений на дальнейшую реализуемость и эффективность инвестиционного проекта. Цель мониторинга заключается в том, чтобы в каждый конкретный момент однозначно определить, выполняются ли условия реализуемости и эффективности бизнес – проекта. По результатам мониторинга может быть либо сделан вывод о необходимости внесения корректировок в план реализации проекта, либо принято решение о прекращении проекта.
По мере выполнения намеченного в бизнес-плане очень важно постоянно проводить мониторинг бизнес-процессов. Мониторинг представляется эффективным инструментом координирования бизнеса. При анализе может выясниться, что проблемы состоят, например, в слабой координации работы персонала или неясности картины происходящего, ее индикаторов. Мониторинг может свидетельствовать о потребности развития управленческого потенциала на основе следующих тенденций в бизнесе:
¦ успешность деятельности компаний определяется степенью результативности проведения рыночной политики, а высший приоритет отдается быстрой реализации бизнес-планов;
¦ важной становится проблема затрат времени, необходимого для выведения продуктов и услуг на рынок;
¦ при распределении всех видов ресурсов необходимо учитывать стратегический подход.
Источник