Эффективное управление автоперевозками. Алексей Дорофеев

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

      Есть и другие немаловажные факторы, которые наводят на определенные раздумья при выборе для внедрения заказного программного обеспечения. Одним из них является дальнейшее техническое сопровождение и поддержка пользователей. Во-первых, любой программный продукт может содержать в себе ошибки. Причем понятие “ошибка в программе” можно трактовать достаточно широко. Это могут быть действительно недоработки программистов по разным причинам, а может быть и так, что в процессе написания программы бизнес-процесс на предприятии изменился или разработчик ТЗ не так понял транспортника. В результате алгоритм программы вроде как соответствует ТЗ, а практически работает не так, как нужно. Это зачастую может вызвать конфликты между заказчиком и исполнителем, ставящие под угрозу реализацию проекта.

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

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

      Очевидно, в этом случае отсутствует необходимость выезда специалистов из внедренческой компании для обучения сотрудников в организацию, которая приобрела информационную систему. Такой подход получил название “вебинар”, от сложения слов “WEB”