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

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

Рис. 1. Структура задач, которые должна решать система управления автопредприятием, по мнению представителей АТП

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

Итак, облик программы для АТП в общих чертах понятен. В некоторых компаниях идут по пути дальнейшего наращивания функционала в существующих Excel-приложениях, о которых было сказано выше. При всей кажущейся простоте такого подхода он является тупиковым. Это прежде всего связано с определенными техническими ограничениями, которые налагает Excel. Как правило, активно используются встроенные функции Excel для выполнения некоторых расчетов, например расхода топлива, также в этой программе очень удобно строить различные отчеты. Как показывает практика, на небольших предприятиях с парком 3–10 автомобилей это не вызывает значительных затруднений. Однако если представить организацию, у которой, допустим, 50 автомобилей, то за месяц необходимо будет обработать 1000–1500 путевых листов. Если учесть при этом, что надо также вести учет резины по пробегам, планировать ТО также по пробегам, то тут уже одними встроенными формулами не обойтись. Пользователи начинают использовать макросы и программирование, что уж требует определенных профессиональных навыков. Я уже не говорю о ведении склада запчастей.

Надо четко понимать, что для хранения и обработки больших массивов данных используются другие программные продукты, которые называются СУБД – системы управления базами данных. Среди приложений Microsoft Office, частью которого является Excel, есть встроенная СУБД Access. С практической точки зрения эта программа более подходит для разработки собственными силами системы учета для автохозяйства. В Access существуют встроенные средства, которые позволяют без программирования строить довольно сложные приложения, удобные для пользователя и решающие широкий круг задач. Таким образом, те работники транспортных предприятий, которые любят работать с компьютером и имеющие достаточное количество свободного времени, могут самостоятельно, не вникая в особенности какого-либо языка программирования, создать в том или ином виде, что называется “под себя”, информационную систему АТП.

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

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

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

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

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

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

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

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