Всегда ли прав клиент?

Евгений Валкин
Генеральный директорфирмы «ФОЛИО 2000»

Материал предоставлен
журналом Бухгалтер и Компьютер №9 2003 год

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

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

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

 

 

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

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

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

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

Не стоит «бояться» массовых, тиражных программ! Наоборот, они помогут предприятию существенно сэкономить средства. Не надо пытаться все делать самим - это, кстати, относится и к постановке задачи. Гораздо выгоднее и эффективнее перенести на деятельность клиента многократно решенную задачу. При этом от него требуется лишь сформулировать конечную цель и ответить на ряд вопросов, которые задаст разработчик.

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

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

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

Десятилетний опыт разработки и эксплуатации финансовых, складских и других программ фирмы «ФОЛИО» для 16 тыс. пользователей дает нам право утверждать, что для многих клиентов можно общими усилиями найти более рациональный и более оптимальный вариант по сравнению с тем, на который ориентируется сам заказчик. Наши специалисты обычно предлагают клиенту такое решение его производственной задачи на основе отработанного готового стандартного решения, которое в полной мере удовлетворяет заказчика. Принимая такой подход, клиент оказывается только в выигрыше.

Статья получена: Клерк.Ру

загрузка...