|
 Слово "аналитик" заменяет слово “специалист” во многих профессиях, происходя из технологического бума 1990-х. С тех пор термин используется для тех, кто включает данные в понятную информацию для отчетов и рекомендации. Сейчас термин "бизнес-аналитик" (BA) делает это для многих предприятий применительно к оперативным функциям и процессам, чтобы повысить эффективность предоставления услуги, производства и управления цепочками поставок.
Влияние глобализации в последнее десятилетие побуждает многие организации пересматривать краткосрочные и долгосрочные стратегии. Эти стратегии выполняются BA и финансовым аналитиком (FA), чтобы выявлять и разрабатывать лучшие методы решения проблем с помощью решений, дающих долговременные выгоды.
Роль бизнес-аналитика может различаться в разных отраслях и организациях, но главный фактор, объединяющий данную профессию, - оценка изменений на предприятии как проекта, использующего много ресурсов для действий, направленных на максимизацию выгод организационной цели. Умелый бизнес-аналитик должен разрабатывать средства для поддержки доверия и уважения со стороны отдела информационных технологий и коммерческого отдела организации. Это подразумевает полный набор навыков, включающий в себя понимание цели организации и роли конкретного проекта в выполнении данной цели. Чтобы достичь этого, бизнес-аналитик должен понимать, что заинтересованные лица, работники и руководство являются внутренними клиентами (IC), которых нужно обслуживать. Поэтому с IC нужно советоваться и расспрашивать их о влиянии, которое конкретный проект может оказать на различные отделы. Можно применять различные методологии, такие как шесть сигм, имеющие более комплексный и структурированный подход к решению проблем. Бизнес-аналитик должен решать проблемы, а не просто устанавливать факты.
Бизнес-аналитикам сейчас часто приходится разбираться с проблемами разработки или модернизации программного обеспечения, чтобы решить различные проблемы с процессами и функциями в организации. Сфера разработки программного обеспечения продолжает развиваться, несмотря на экономический спад, и профессия бизнес-аналитика является востребованной, так как фирмы объединяют разные функции, чтобы использовать технологии для сокращения затрат. Типовые задачи BA включают в себя, но не ограничиваются техническими требованиями, требованиями к коммуникации, оценкой программного обеспечения, контролем качества, анализом осуществимости, разработкой систем, реализацией систем, документированием и обучением персонала. Иногда требуется разработка программного обеспечения жизненного цикла (SDLC). Роль BA очень важна, и поэтому методологии пользовательского приёмочного тестирования (UAT) являются незаменимыми инструментами на пути к завершению проекта.
Грубым заблуждением является считать, что деятельность бизнес-аналитика в основном связана с созданием диаграмм, графиков и статистических выкладок. Старая модель перестройки бизнес-процессов (BPRM) была заменена моделью бизнес-проектирования (BEM). Разница в том, что BA раньше использовали BPRM для проектов, перестраивавших текущую коммерческую модель, чтобы она соответствовала некоторой отрасли или потребности в организации. Некоторые возразят, что это использование такой же структуры с другим процессом. Современный метод BEM заключается в разработке новых процессов и функций в рамках такой же структуры с улучшениями, или в переделывании части или всей организационной структуры постепенно или полностью. BEM обеспечивает большую гибкость и требует меньше ресурсов, что не повлияет на другие отделы организации в плане времени простоя сети или переходного периода. Путем выработки оценки и знания обеих стратегий BA повышает эффективность работы организации.
Основа успеха BA - умение рассматривать внутренние отделы, поставщиков и заинтересованных лиц как долевых партнеров в группе, сосредотачиваясь на обеспечении завершения проекта. Он должен иметь представление о сложившейся ситуации, которую проект должен разрешить, и ожидаемых результатах, нужных заинтересованным лицам. Задача BA – решить проблему между существующим положением вещей и ожидаемым результатом. В данной сфере BA должен выполнять основную часть своей работы. Ниже перечислены общие меры, помогающие в его начинании.
Шаблон разработки бизнес-аналитиком программного обеспечения жизненного цикла:
1. Встретиться с заинтересованными лицами (руководители, поставщики и конечные пользователи), чтобы выявить ориентировочные вопросы, относящиеся к проблеме. Цель – получить разные мнения о макро- и микросостоянии проблемы.
2. Выработать точное описание основной проблемы, согласованное с заинтересованными лицами. Таким образом, все стороны поймут суть проблемы в одном-двух кратких предложениях.
3. Создать имя проекта. Утвердить заданные средства связи по телефону, через папки с документами, с помощью электронной почты или доски объявлений в локальной сети.
4. Выбрать определенных заинтересованных лиц в качестве бета-тестировщиков нового ПО.
5. Встретиться с группой разработчиков ИТ (ITDT), чтобы подробно описать крупномасштабную проблему, с согласованной датой встречи, чтобы передать больше информации. Хороший BA также устанавливает, что с ним можно связаться в любое время на протяжении всего проекта для получения более подробной информации о проекте.
6. BA должен начать анализ осуществимости, включающий в себя опросы руководителей, конечных пользователей и глав отделов касательно системы, технических деталей, коммуникаций, процесса и функциональных требований. Вопросы опроса должны проверять существенные элементы проекта, чтобы предотвратить сбор не важной информации.
7. Собранную информацию нужно проанализировать на предмет бюджета и расходов и представить заинтересованным лицам на утверждение. В некоторых организациях могут требоваться финансовые аналитики для проверки бюджетных требований.
8. После утверждения BA должен предъявить ITDT полную схему проекта. Подробная блок-схема с использованием UML, SAP или Visio должна показывать ожидаемый результат. BA должен подробно сообщить ITDT, что требуется на стороне компании, отвечая без подготовки на любые вопросы или опасения.
9. BA должен начать тщательно документировать предлагаемые изменения в существующей системе, чтобы создать справочник для обучения и поддержки конечных пользователей к концу проекта. Наиболее эффективный способ для экономии ресурсов и времени – разработать сайт в локальной сети компании, предназначенный для поддержки и обучения, с использованием модели ITIL Foundation. Также разработать доску объявлений для отзывов об улучшениях.
10. Оставаться доступным для заинтересованных лиц и ITDT, чтобы они передавали заявки на модификацию и другие сведения, способные повлиять на проект.
11. Встретиться с заинтересованными лицами, чтобы оценить предварительные результаты по первой версии программного обеспечения. Передать плюсы и минусы и рекомендации от бета-тестировщиков ITDT касательно изменений.
12. Проверить улучшения, сделанные для утверждения пользователем. Убедиться, что все ошибки и проблемы документально зафиксированы на будущее.
13. После утверждения окончательного варианта ПО сжато выразить информацию, имеющуюся в документации, в виде краткого полноценного документа Word или PDF для инструкции.
14. Проверять новую систему после полной реализации на наличие ошибок, конфликтов или неполадок. Измерять улучшения по сравнению с модификациями системы.
15. Начать новый цикл улучшений тогда, когда оговорено в пункте 1.
Цель данного краткого шаблона – дать краткое описание процесса с участием бизнес-аналитика. Приведенные шаги и процедуры могут различаться в разных компаниях или отраслях, но должность бизнес-аналитика никогда не кончается.
|
