Слушать и слышать

Проблема взаимодействия заказчиков и подрядчиков, о которой мы уже говорили, имеет много граней. Одна из них – взаимодействие с вендорами бизнес-приложений, возможность вносить в программные продукты необходимые изменения. Мировые гранды ИТ-индустрии обычно имеют налаженные механизмы взаимодействия со своими клиентами, общаются с ними на специальных конференциях, так или иначе стараются «держать руку на пульсе». И если вы BankofAmerica, то скорей всего вас поставщик услышит. Но если мы говорим о российской реальности, то картина не выглядит такой уж радостной даже для крупных клиентов крупных вендоров.

Разумеется, размер имеет значение, и странно было бы скромному холдингу «Балалайкин и К» ожидать к себе такого же отношения, на какое рассчитывает, скажем, GM. Однако дело, скорей всего, не только в масштабах бизнеса, ведь и поставщики ПО – не все гиганты. Удачные практики взаимодействия не стали еще нормой, как кажется. Обмен опытом в этой сфере, знакомство с примерами хорошо построенного процесса сбора требований имеет смысл.

Вот что говорит об этом Владимир Капустин, возглавлявший внедрение ERP-системы на ЗАО "Тихвинский вагоностроительный завод"(Россия, Тихвин): «Когда выбиралась система автоматизации для Тихвинского вагоностроительного завода, мы исследовали продукты и подходы разных вендоров. Когда стали рассматривать Infor, связались с Liеbherr, их давним и крупным клиентом, съездили к ним на завод. И убедились в том, о чем я слышал и раньше: у этого вендора, в отличие от многих других, действительно выстроена система взаимодействия с крупными заказчиками.

Это налаженная система сбора требований. С клиентами непосредственно работают бизнес-аналитики вендора. Они собирают требования, рассматривают, обсуждают, собирают представителей заказчиков. И на этой базе решают, куда дальше вести разработку. Взаимодействие начинается с высших руководителей разработки. Их позиция такова: не надо придумывать «сферического коня в вакууме». У серьезных заказчиков, если это компания номер один в своей отрасли, наверняка есть идеи и требования, которые нужны многим. Именно так было и с Liеbherr: ряд процессов которые они дорабатывали для BaanIV были включены в стандартную версию InforLN.

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

Используется и другой путь. Во всех крупных проектах в ходе внедрения появляются дополнительные требования. Бизнес аналитики вендора все их собирают и сортируют на существенные и те, которыми нет смысла заниматься. Таким образом все, что выявляется в проектах начиная с определенного масштаба, не ложится в архив, а берется в работу.

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

Я работал и с продуктами SAP и Oracle, но у этих вендоров таких действенных механизмов я не видел. Такой корпоративной культуры взаимоотношений с клиентами, как у Infor, я больше не встречал».

А каков ваш опыт взаимодействия с производителями ПО? Мировыми и российскими? Положительный и отрицательный? Какие методы, формы трансляции своих требований вы считаете наиболее продуктивными?