Зачем нужен аналитик на проектах внедрения ИС

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

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

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

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

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

Что делает аналитик?

Понимает потребности клиента.

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

●    С какой целью будет использоваться новое поле?

●    Для чего нужно видеть это поле?

●    Какая информация будет передаваться в нем?

●    Откуда берется эта информация?

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

Разбирается в понятийном аппарате клиента и правильно доносит его смысл до разработчика.

Если компания Б попросит реализовать электронный факторинг, то разработчик, который в сфере финансов, возможно, никогда не работал, просто ничего не поймет. Понимать, что такое факторинг, уступка права требования, уступочная надпись, разговаривать на этом языке с заказчиком и донести понятно до разработчика и остальных членов команды – как раз задача аналитика.

Систематизирует и визуализирует полученную информацию.

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

●    изобразить бизнес-процесс схематически и коротко его описать;

●    выделить потребности и требования клиента, которые касаются создания новой системы или изменения существующей;

●    обсудить и согласовать с заказчиком приоритеты реализации требований.

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

●    из общения с заказчиком и будущими пользователями, которые из первых уст расскажут, что хотят от новой системы;

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

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

●    из требований законодательства, например, к форматам электронных документов.

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

Как действует аналитик?

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

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

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

●    Он будет консультировать разработчиков и представителей заказчика по предметной области и возможностям системы.

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

●    Если будет нужна документация, он поможет в ее составлении.

Что получает клиент, благодаря участию аналитика?

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

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

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

И еще несколько плюсов:

●    Аналитик знает, почему это не баг, а фича. А если не знает, то разберется.

●    Аналитик закидает вас вопросами, но в итоге предложит множество разных вариантов.

●    Аналитик спасает разработчиков от общения с клиентом, а клиента от общения с разработчиками.

В свою очередь аналитики Synerdocs готовы не только оказать разностороннюю помощь на проекте, но и проконсультировать по самым различным темам - от применения электронной подписи до подключения контрагентов. Ежемесячно в разделе "Консультации" на сайте www.synerdocs.ru аналитики отвечают на вопросы пользователей, доказывая свою компетентность во многих аспектах ЭДО.

Ну и в преддверии наступающих праздников, чтобы улыбнуться, вот вам анекдот из жизни аналитиков:

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

Источник: Synerdocs