Бизнес-аналитик: свой человек за линией фронта...
Нашел сразу несколько статей про то, кто такой бизнес-аналитик. В принципе, это примерно похоже на то, чем я занимаюсь. Читая, еще раз убеждаюсь, что я выполняю функции именно бизнес-аналитика. Да и вообще, в моем понимании, современная поставнока планово-экономической работы связана в большей степени именно с бизнес-аналитикой, чем с каким-либо иным направлением деятельности...
Бизнес-аналитик свой человек за линией фронта
Б. Шлаин
независимый консультант»
http://www.borisshlain.com
15 ноября 2005
Введение
Бизнес-аналитик - это, с точки зрения клиента, еще или уже не программист. Это человек, которому можно рассказать о бизнесе примерно так же, как пожаловаться своему врачу - и он должен где-то посоветовать лекарство, а где-то просто успокоить словом. А для руководителя группы разработки и архитектора бизнес-аналитик - это такой агент, шпион, которого можно «забросить за линию фронта» в компанию-клиента, чтобы он добыл ценные сведения о пожеланиях клиента и его стратегии развития своего бизнеса.
Сегодня под словом «бизнес-аналитик» скрывается две разные профессии...
Бизнес-аналитик в информационных технологиях - это человек, выступающий в роли интерфейса между ИТ и бизнесом, который может говорить на одном языке с представителями обеих областей и может организовать совместную работу над предметной областью. Его главная задача - сделать так, чтобы информационная система отвечала потребностям бизнеса. Бизнес-аналитик может быть связан с каким-либо определенным продуктом (консультанты по SAP), с узкой специализацией (розничные продажи и логистика скоропортящихся продуктов) или с конкретным предприятием (бизнес-технологи, работающие в ИТ-отделах крупных компаний).
Бизнес-аналитик в бизнесе - это человек, который умеет анализировать определенный вид бизнеса или процесса (непрерывное производство, розничный бизнес, управление проектами и т.п.) или круг задач в бизнесе (маркетинг, управление запасами, бюджетирование и т.д.). Его арсенал - это совокупность методик, а средства автоматизации являются при этом вспомогательными.
Иногда оба бизнес-аналитика оказываются как «два в одном». Однако особенности специальности в любом случае следует учитывать: человек, умеющий настраивать и внедрять аналитическую систему, не всегда может адекватно и качественно оценить результаты анализа с точки зрения бизнеса. В подобном случае могут потребоваться оба специалиста - практически как «ведущий» и «ведомый».
Бизнес-аналитик может представлять в проекте ИТ-компанию, компанию-клиента или быть независимым консультантом, приглашенным на проект. При этом функциональная роль бизнес-аналитика - интерфейс между бизнесом и ИТ - остается практически постоянной, вне зависимости от «юрисдикции». В этой статье «по умолчанию» бизнес-аналитик рассматривается как сотрудник ИТ-компании, однако большинство высказываний сохранит свою справедливость и для других случаев.
Бизнес-аналитик на проекте
Как выглядит разработка автоматизированных систем без бизнес-аналитика? К сожалению, видеть подобную организацию процесса приходится слишком часто. Задачи ставятся конечными пользователями программистам или в лучшем случае руководителю разработки. Программисты используют при разработке или собственную модель, или предложенную конечными пользователями. В первом случае достаточно быстро наступает момент, когда модель перестает соответствовать реальному бизнесу; во втором проекту угрожают противоречия внутри самой модели.
Основная роль бизнес-аналитика - это разработка непротиворечивой и достаточно полной модели требований реального бизнеса. Это задача не столько описательная и созерцательная («просто напишите, как у нас все происходит и автоматизируйте»), а творческая. Уже расхожим стало выражение об «автоматизации беспорядка», которая только ухудшает общую ситуацию. Но и «прямолинейная автоматизация» очень часто исключает из процесса те самые «отдушины» и «обходные пути», которые и обеспечивают известную российскую «нестрогость законов» и позволяют бизнес-системе в целом работать.
Соавторами бизнес-аналитика при разработке модели требований являются ключевые пользователи (или потенциальные пользователи). Таким образом, на этапе анализа задача бизнес-аналитика - собрать требования, построить непротиворечивую полную модель и «продать», представить ее клиенту.
Но достаточно часто бизнес-аналитик приступает к работе еще на этапе переговоров. В этом случае его задача - понять, насколько решение соответствует потребностям клиента, оценить «масштабы бедствия» и определить возможный объем доработок.
Однако переговорами и согласованием требований работа бизнес-аналитика в проекте, конечно, не ограничивается - хотя достаточно часто именно после согласования технического задания аналитика перебрасывают на другой проект. Известно, что требования имеют обыкновение изменяться и «плохо ложиться» на архитектуру - именно поэтому бизнес-аналитик должен сопровождать проект и на этапе проектирования, и на этапе разработки. Конечно, такая работа может уже не требовать 100% загрузки (это зависит от масштабов проекта), но она, в совокупности с регулярным представлением клиенту результатов, позволяет процессу разработки не уходить в сторону от требований бизнеса. Задача клиента - требовать, чтобы бизнес-аналитик продолжал сопровождать проект, и со своей стороны работать над проектными документами: техническим заданием, спецификацией требований, запросами на изменения. Только полнота и актуальность этих документов позволят при необходимости вовлечь в проект новых или дополнительных сотрудников.
Особая роль принадлежит бизнес-аналитику на этапе внедрения. Его задача - «вписать» средства автоматизации в реальный бизнес-процесс. Бизнес-аналитик не обязательно разрабатывает документацию сам и тем более не обязательно непосредственно руководит внедрением - он формулирует требования, каркас документации и совместно с менеджером внедрения разрабатывает модель эксплуатации системы, решая задачи соответствия организационных и технических решений.
То, что написано выше - не связано с какой-либо конкретной методологией RUP, MSF, ASAP и т.п., а есть некоторое обобщение их и практических подходов нескольких российских фирм.
Безусловно, роль и название должности бизнес-аналитика могут изменяться от компании к компании и даже от проекта к проекту. Общим должны оставаться - творческая, созидательная направленность работы и сквозное сопровождение решений от анализа до внедрения.
Отдельный вопрос - а может ли работа бизнес-аналитика совмещаться с другими функциями, например: руководителя разработки, менеджера проекта, архитектора? Это зависит в значительной степени от личных качеств человека. Руководство требует волевых качеств, анализ - творческих. При их сочетании в одном человеке, в небольшом проекте эти два роли могут быть совмещены.
Бизнес-аналитик может выполнять функции архитектора, если он осознает, что это две различные роли, и анализ и проектирование - два различных этапа в процессе. В этом случае, если квалификация в области современных архитектуры и средств проектирования позволяет, эти две роли могут быть совмещены. Большие проблемы могут возникнуть, если сотрудник совмещает роли бизнес-аналитика на одном проекте и проектирует при этом решение, которое будет использоваться как универсальное, в нескольких проектах.
Совмещение роли разработчика, или руководителя разработки, и бизнес-аналитика крайне нежелательно: это люди имеют противоположные взгляды на проект. Есть большая опасность, что результатом анализа будет неоформленная, противоречивая модель, которая потом будет непосредственно реализована в программный код. Подобный подход в России почему-то принято называть экстремальным программированием, при этом часто забываются основные принципы eXtremal Programming: предварительная разработка тестовых примеров совместно с клиентом, обязательная парная работа программистов над задачами и разработка решений сугубо «под конкретного заказчика».
Какой он, хороший бизнес-аналитик?
С точки зрения клиента, это человек, способный быстро понять требования и определить их приоритет, а также рассказать о технических решениях и их влиянии на бизнес понятным клиенту языком. При этом клиент вправе ожидать от бизнес-аналитика наличия систематизированных знаний о предметной области, а также опыта аналогичных проектов в других предприятиях. Иногда бизнес-аналитику приходится предлагать организационные схемы за рамками автоматизированной системы - «а как же отдел будет работать, пока ваш модуль еще не внедрен».
С точки зрения директора компании, это человек, который играет важную роль в проектах и сохраняет лояльность своей компании, участвуя в переговорах и совместных рабочих группах. Уход из компании бизнес-аналитика - это потеря капитала, утечка знаний: при этом в реальности «утечка» может произойти и без формальной смены работодателя.
С точки зрения руководителя отдела анализа, это человек, который может в различных проектах следовать принятой методологии, нотациям и формам документов; достаточно важным является также умение работать с соответствующим программным обеспечением. Есть еще один, достаточно болезненный вопрос - способность к коллективной работе с другими аналитиками.
В проектной команде бизнес-аналитик играет уникальную роль, в своем отделе он один среди многих. При этом компания может получить синергетический эффект, если ее интеллектуальный штаб работает именно совместно, совершенствуя подходы, критикуя и обсуждая собственные решения.
Для руководителя отдела подход сотрудника «это мое решение, я не буду им делиться и не позволю его критиковать» категорически неприемлем, а в действительности такое встречается нередко - творческим личностям свойственны амбиции и индивидуализм.
С точки зрения руководителя проекта, это человек, который, сохраняя творческий стиль работы, соблюдает дисциплину в отношении ведения документов, версий, протоколов и готов работать в команде с архитекторами, разработчиками, тестировщиками. Солидарность с командой здесь очень важна, так как успех в этом смысле может быть только общим, и позиция по отношению к разработке «требования собраны, а как их реализовывать - не мое дело» неприемлима.
С точки зрения руководителя разработки (team leader), это человек, который готов работать с командой и после формального завершения анализа, сопровождая собственные решения и давая разработчикам пояснения. Бизнес-аналитик - это по сути «информационный» представитель клиента в проекте по всем вопросам, касающимся требований и предметной области - в отличие от менеджера проекта, который является «административным» представителем клиента.
С точки зрения менеджера по продажам, это человек, способный быстро и убедительно продемонстрировать компетенцию компании в определенной области, по итогам краткого разговора составить представление о клиенте и его требованиях к решению. При этом он еще и осознает предел своей квалификации и не вмешивается в ходе переговоров в политические и коммерческие вопросы.
Итак, у бизнес-аналитика семь нянек? - И да, и нет. Конечно, сам он может сформулировать свои пожелания ко всем перечисленным лицам. Но если уж мы начали «склонять» бизнес-аналитика как интерфейс, то придется согласиться - интерфейс сильно зависит от того, что он связывает.
Бизнес-аналитик свой человек за линией фронта
Б. Шлаин
независимый консультант»
http://www.borisshlain.com
15 ноября 2005
Введение
Бизнес-аналитик - это, с точки зрения клиента, еще или уже не программист. Это человек, которому можно рассказать о бизнесе примерно так же, как пожаловаться своему врачу - и он должен где-то посоветовать лекарство, а где-то просто успокоить словом. А для руководителя группы разработки и архитектора бизнес-аналитик - это такой агент, шпион, которого можно «забросить за линию фронта» в компанию-клиента, чтобы он добыл ценные сведения о пожеланиях клиента и его стратегии развития своего бизнеса.
Сегодня под словом «бизнес-аналитик» скрывается две разные профессии...
Бизнес-аналитик в информационных технологиях - это человек, выступающий в роли интерфейса между ИТ и бизнесом, который может говорить на одном языке с представителями обеих областей и может организовать совместную работу над предметной областью. Его главная задача - сделать так, чтобы информационная система отвечала потребностям бизнеса. Бизнес-аналитик может быть связан с каким-либо определенным продуктом (консультанты по SAP), с узкой специализацией (розничные продажи и логистика скоропортящихся продуктов) или с конкретным предприятием (бизнес-технологи, работающие в ИТ-отделах крупных компаний).
Бизнес-аналитик в бизнесе - это человек, который умеет анализировать определенный вид бизнеса или процесса (непрерывное производство, розничный бизнес, управление проектами и т.п.) или круг задач в бизнесе (маркетинг, управление запасами, бюджетирование и т.д.). Его арсенал - это совокупность методик, а средства автоматизации являются при этом вспомогательными.
Иногда оба бизнес-аналитика оказываются как «два в одном». Однако особенности специальности в любом случае следует учитывать: человек, умеющий настраивать и внедрять аналитическую систему, не всегда может адекватно и качественно оценить результаты анализа с точки зрения бизнеса. В подобном случае могут потребоваться оба специалиста - практически как «ведущий» и «ведомый».
Бизнес-аналитик может представлять в проекте ИТ-компанию, компанию-клиента или быть независимым консультантом, приглашенным на проект. При этом функциональная роль бизнес-аналитика - интерфейс между бизнесом и ИТ - остается практически постоянной, вне зависимости от «юрисдикции». В этой статье «по умолчанию» бизнес-аналитик рассматривается как сотрудник ИТ-компании, однако большинство высказываний сохранит свою справедливость и для других случаев.
Бизнес-аналитик на проекте
Как выглядит разработка автоматизированных систем без бизнес-аналитика? К сожалению, видеть подобную организацию процесса приходится слишком часто. Задачи ставятся конечными пользователями программистам или в лучшем случае руководителю разработки. Программисты используют при разработке или собственную модель, или предложенную конечными пользователями. В первом случае достаточно быстро наступает момент, когда модель перестает соответствовать реальному бизнесу; во втором проекту угрожают противоречия внутри самой модели.
Основная роль бизнес-аналитика - это разработка непротиворечивой и достаточно полной модели требований реального бизнеса. Это задача не столько описательная и созерцательная («просто напишите, как у нас все происходит и автоматизируйте»), а творческая. Уже расхожим стало выражение об «автоматизации беспорядка», которая только ухудшает общую ситуацию. Но и «прямолинейная автоматизация» очень часто исключает из процесса те самые «отдушины» и «обходные пути», которые и обеспечивают известную российскую «нестрогость законов» и позволяют бизнес-системе в целом работать.
Соавторами бизнес-аналитика при разработке модели требований являются ключевые пользователи (или потенциальные пользователи). Таким образом, на этапе анализа задача бизнес-аналитика - собрать требования, построить непротиворечивую полную модель и «продать», представить ее клиенту.
Но достаточно часто бизнес-аналитик приступает к работе еще на этапе переговоров. В этом случае его задача - понять, насколько решение соответствует потребностям клиента, оценить «масштабы бедствия» и определить возможный объем доработок.
Однако переговорами и согласованием требований работа бизнес-аналитика в проекте, конечно, не ограничивается - хотя достаточно часто именно после согласования технического задания аналитика перебрасывают на другой проект. Известно, что требования имеют обыкновение изменяться и «плохо ложиться» на архитектуру - именно поэтому бизнес-аналитик должен сопровождать проект и на этапе проектирования, и на этапе разработки. Конечно, такая работа может уже не требовать 100% загрузки (это зависит от масштабов проекта), но она, в совокупности с регулярным представлением клиенту результатов, позволяет процессу разработки не уходить в сторону от требований бизнеса. Задача клиента - требовать, чтобы бизнес-аналитик продолжал сопровождать проект, и со своей стороны работать над проектными документами: техническим заданием, спецификацией требований, запросами на изменения. Только полнота и актуальность этих документов позволят при необходимости вовлечь в проект новых или дополнительных сотрудников.
Особая роль принадлежит бизнес-аналитику на этапе внедрения. Его задача - «вписать» средства автоматизации в реальный бизнес-процесс. Бизнес-аналитик не обязательно разрабатывает документацию сам и тем более не обязательно непосредственно руководит внедрением - он формулирует требования, каркас документации и совместно с менеджером внедрения разрабатывает модель эксплуатации системы, решая задачи соответствия организационных и технических решений.
То, что написано выше - не связано с какой-либо конкретной методологией RUP, MSF, ASAP и т.п., а есть некоторое обобщение их и практических подходов нескольких российских фирм.
Безусловно, роль и название должности бизнес-аналитика могут изменяться от компании к компании и даже от проекта к проекту. Общим должны оставаться - творческая, созидательная направленность работы и сквозное сопровождение решений от анализа до внедрения.
Отдельный вопрос - а может ли работа бизнес-аналитика совмещаться с другими функциями, например: руководителя разработки, менеджера проекта, архитектора? Это зависит в значительной степени от личных качеств человека. Руководство требует волевых качеств, анализ - творческих. При их сочетании в одном человеке, в небольшом проекте эти два роли могут быть совмещены.
Бизнес-аналитик может выполнять функции архитектора, если он осознает, что это две различные роли, и анализ и проектирование - два различных этапа в процессе. В этом случае, если квалификация в области современных архитектуры и средств проектирования позволяет, эти две роли могут быть совмещены. Большие проблемы могут возникнуть, если сотрудник совмещает роли бизнес-аналитика на одном проекте и проектирует при этом решение, которое будет использоваться как универсальное, в нескольких проектах.
Совмещение роли разработчика, или руководителя разработки, и бизнес-аналитика крайне нежелательно: это люди имеют противоположные взгляды на проект. Есть большая опасность, что результатом анализа будет неоформленная, противоречивая модель, которая потом будет непосредственно реализована в программный код. Подобный подход в России почему-то принято называть экстремальным программированием, при этом часто забываются основные принципы eXtremal Programming: предварительная разработка тестовых примеров совместно с клиентом, обязательная парная работа программистов над задачами и разработка решений сугубо «под конкретного заказчика».
Какой он, хороший бизнес-аналитик?
С точки зрения клиента, это человек, способный быстро понять требования и определить их приоритет, а также рассказать о технических решениях и их влиянии на бизнес понятным клиенту языком. При этом клиент вправе ожидать от бизнес-аналитика наличия систематизированных знаний о предметной области, а также опыта аналогичных проектов в других предприятиях. Иногда бизнес-аналитику приходится предлагать организационные схемы за рамками автоматизированной системы - «а как же отдел будет работать, пока ваш модуль еще не внедрен».
С точки зрения директора компании, это человек, который играет важную роль в проектах и сохраняет лояльность своей компании, участвуя в переговорах и совместных рабочих группах. Уход из компании бизнес-аналитика - это потеря капитала, утечка знаний: при этом в реальности «утечка» может произойти и без формальной смены работодателя.
С точки зрения руководителя отдела анализа, это человек, который может в различных проектах следовать принятой методологии, нотациям и формам документов; достаточно важным является также умение работать с соответствующим программным обеспечением. Есть еще один, достаточно болезненный вопрос - способность к коллективной работе с другими аналитиками.
В проектной команде бизнес-аналитик играет уникальную роль, в своем отделе он один среди многих. При этом компания может получить синергетический эффект, если ее интеллектуальный штаб работает именно совместно, совершенствуя подходы, критикуя и обсуждая собственные решения.
Для руководителя отдела подход сотрудника «это мое решение, я не буду им делиться и не позволю его критиковать» категорически неприемлем, а в действительности такое встречается нередко - творческим личностям свойственны амбиции и индивидуализм.
С точки зрения руководителя проекта, это человек, который, сохраняя творческий стиль работы, соблюдает дисциплину в отношении ведения документов, версий, протоколов и готов работать в команде с архитекторами, разработчиками, тестировщиками. Солидарность с командой здесь очень важна, так как успех в этом смысле может быть только общим, и позиция по отношению к разработке «требования собраны, а как их реализовывать - не мое дело» неприемлима.
С точки зрения руководителя разработки (team leader), это человек, который готов работать с командой и после формального завершения анализа, сопровождая собственные решения и давая разработчикам пояснения. Бизнес-аналитик - это по сути «информационный» представитель клиента в проекте по всем вопросам, касающимся требований и предметной области - в отличие от менеджера проекта, который является «административным» представителем клиента.
С точки зрения менеджера по продажам, это человек, способный быстро и убедительно продемонстрировать компетенцию компании в определенной области, по итогам краткого разговора составить представление о клиенте и его требованиях к решению. При этом он еще и осознает предел своей квалификации и не вмешивается в ходе переговоров в политические и коммерческие вопросы.
Итак, у бизнес-аналитика семь нянек? - И да, и нет. Конечно, сам он может сформулировать свои пожелания ко всем перечисленным лицам. Но если уж мы начали «склонять» бизнес-аналитика как интерфейс, то придется согласиться - интерфейс сильно зависит от того, что он связывает.