1. Предприятие достаточно мало и само специализируется исключительно на оказании транспортных услуг. В таком случае никакого взаимодействия не потребуется, можно применять любое популярное решение в сфере автоматизации в роли корпоративной информационной системы, все отчеты формировать там же, с незначительной модификацией по необходимости.
Пример: Транспортное предприятие, имеющее в собственности 20-30 автомобилей, ремонтную мастерскую, и получающее заказы от одного постоянного контрагента, не имеющее коммерческой службы, подавляющее большинство сотрудников - водители.
Отрицательный момент может возникнуть в перспективе: если компания развивается и диверсифицирует бизнес, информационную систему придется серьезно модифицировать.
2. Транспортный блок предприятия незначителен, для его учета не требуется серьезных ресурсов, небольшой объем данных можно учитывать и анализировать в имеющейся корпоративной информационной системе с незначительными доработками.
Пример: в организации 3-4 автомобиля, нет склада запчастей, ремонт автомобилей производится в сторонней ремонтной мастерской. Водители ежемесячно получают топливную карту со средним лимитированным количеством топлива, рассчитанным опытным путем за годы работы предприятия.
Недостаток подобного варианта также только в том что, со временем отношение к автотранспортному подразделению может поменяться и потребуется модификация информационной системы с целью детализации учета.
3. Получение необходимых данных из отдельной системы учета автотранспорта и внесение их в корпоративную систему для сопоставления, анализа и получения консолидированной отчетности.
Пример: Холдинговая компания имеет в составе автотранспортное подразделение, еженедельно экономист составляет в системе учета автотранспорта отчет по расходу топлива и вносит итоговую сумму на определенную статью расходов холдинга в единую систему, из которой ежемесячно формируется отчет для акционеров.
Отрицательные стороны этого подхода очевидны:
• Наличие человеческого фактора в процессе обработки данных допускает появление ошибок в консолидированных отчетах, сформированных из данных, введенных вручную. В двух различных системах хранятся одни и те же данные, не ясен приоритет этих данных.
• При большом объеме данных существенно увеличивается время, требуемое для создания отчетности.

4. Создание и регламентирование автоматической процедуры обмена данными.
Этот подход гораздо привлекательнее предыдущего, при неизменной итоговой логике, влияние человеческого фактора исключается полностью, при увеличении объема данных время на обработку увеличивается незначительно. Пример: экономисту из предыдущего примера данные требуются не еженедельно, а ежедневно, и не только по топливу, но и данные километража.
Минусы данного подхода следующие:
• При сложной структуре данных возрастает стоимость разработки процедуры обмена данными. То же самое происходит при кросс-платформенном обмене данными (когда система учета автотранспорта и корпоративная информационная система функционируют на разных платформах, например Рарус-Автотранспорт на платформе 1С Предприятие и Microsoft Dynamics AX).
• При внешней связи двух приложений вероятность сбоя процедуры увеличивается за счет привлечения внешних факторов (например, работа локальной сети или устойчивость интернет канала)

5. Интеграция транспортного блока в единую корпоративную систему при наличии единой платформы приложения.
Данный подход исключает какую-либо зависимость взаимодействия блоков от внешних факторов, а также является экономичным с точки зрения хранения данных (исключен дублированный ввод данных, одни и те же цифры не нужно вводить в двух различных системах).
Пример: В холдинге происходит расчет зарплаты всех шестисот пятидесяти водителей совместно с другими сотрудниками, экономисту все также требуются данные по топливу и километражу, бухгалтерия рассчитывает реальную амортизацию автомобилей, а директор хочет видеть зависимость расходов на ремонт автомобилей от увеличения числа продаж продуктов питания.
Стоимость такой интеграции может существенно варьироваться в зависимости от различных настроек и методов разработки систем.
Отрицательные моменты подхода следующие:
• Вариант имеет важное ограничение - использование двух решений на одной платформе (например, 1С Предприятие 7.7).
• Также появляется проблема обновления типовых решений. При каждом таком обновлении потребуется вмешательство разработчика.
• Консолидированная система может получиться неоправданно «тяжелой» за счет универсальности типовых решений корпоративной информационной системы и системы учета автотранспорта.

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

Гаврилов В.В.
руководитель проектов.