Роль штатного бизнес-аналитика

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

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

Если речь идет о сравнительно крупной компании - скажем, от 300 человек, то я, безусловно, соглашусь. Но зачастую в компаниях со штатом в 150-200 сотрудников (преимущественно - "офисных") необходимость в бизнес-аналитике уже есть, а средств на Service Desk пока нет (я имею в виду Service Desk в вопросах протекания бизнес-процессов).

А как часто приходилось Вам встретить в компании на 150-200 сотрудников ("даже офисных"), или даже свыше 300 сотрудников полный пакет документов по бизнес-процессам (соглашения, описания, регламенты) и сами средства автоматизации бизнес-процессов (кроме Visio или встроенных в другие системы автоматизации)? Большинство руководителей, не говоря уж о рядовых сотрудниках, имеет смутное представление не только об оптимизации, но и о самих бизнес-процессах и с чем их "едят". Зачастую, используя в качестве нотации IDEF0, схемы процессов понятны узкому кругу сотрудников. А одна презентация или встреча вряд ли поможет.

А вот насчет программирования я в корне не согласен. Если аналитик не имеет хотя бы минимального опыта программирования, то сколько же времени необходимо ему, чтобы объяснить отдельному программеру, "Чего хотят женщины?" И тогда стоит соотнести его затраченное время на создание "ТехЗадания" с временем, потраченным на внесение изменений (или дополнений) в существующие модели бизнес-процессов.

Отвечать на вопросы "Как лучше сделать ту или иную работу" - явно прерогатива непосредственного руководителя. Мини Servis-Desk по вопросам протекания - тема реальная, но неплохо бы к ней подцепить инструмент оценки потраченного времени и результатов консультации (например: с 1 по 6 апреля 2007 г. проведено 7 консультаций сотрудников из 3 отделов, потрачено 4 часа, с 8 по 14 апреля проведено 5 консультаций сотрудников из 2 отделов, потрачено 2 часа). 

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

Даже в компании из 150-200 человек. Я не утверждаю, что это есть у всех таких компаний, но необходимость в описании процессов в компании из 200 "офисных" сотрудников уже очень высока.

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

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

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