Новые цели и новый взгляд на автоматизацию транспортно-логистических компаний



В чем нуждаются логистические компании в постановке учета или в построении управлении процессами? Как развивался рынок автоматизации логистики, как меняется представление рынка об автоматизации…

Написать данную статью меня побудило долгое, с 2003 года, наблюдение и, что уж греха таить, участие в качестве компании-разработчика на рынке программных продуктов для транспортно-логистических компаний. Все что, описано ниже, является исключительно личным мнением автора.

Если обобщать, то рынок программного обеспечения идет вслед за реальным сектором экономики. Растет экономика – растет и рынок программного обеспечения, меняется экономическая ситуация – меняются и требования к ПО. Если оглянуться назад не в 90-е, а в 2000-е, то можно заметить несколько закономерностей. В принципе они касаются всего рынка программного обеспечения, но в данной статье мы будем говорить только о программном обеспечении для транспортно-логистических компаний. Ниже привожу наиболее характерные стадии развития рынка транспортно-логистических услуг и типичные для данной стадии требования к программному обеспечению и автоматизации бизнеса:

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

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

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

  • Рынок устоявшийся, количество игроков на рынке достигло предела, обострилась конкуренция, маржинальность прошлых периодов только снится. Нужно повышать эффективность транспортно-логистической деятельности и снижать непроизводительные издержки, за клиентов приходится бороться. Требования к автоматизации, несмотря на явные изменения на рынке, изменились мало – максимально дешево и чтобы учитывала. Единственное, что добавляется, – желание найти некий типовой программный продукт, который можно было бы установить и сразу начать работать. Это, к сожалению, утопия! Единственная сфера, где это желание резонно и достижимо, – это бухгалтерский, налоговый и кадровый учет, которые все компании, вне зависимости от отрасли и сферы деятельности, обязаны вести в жестком соответствии с единым для всех набором законодательных требований.

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

  • Инфографика - учетная система

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

Как же быть? С одной стороны, просто строить информационную систему или программный продукт от бизнес-процессов и принять за постулат, что документы вторичны, не в том смысле, что они не важны, вовсе нет, важны, но являются следствием происходящих в компании процессов. С другой стороны, такой подход существенно усложняет жизнь вендору, т.к. гораздо проще автоматизировать регистрацию конечного документа, чем реализовывать различные варианты, комбинации и взаимосвязи бизнес-процессов, которые приводят к созданию этого документа. Т.е., получается документ один – но вариаций бизнес-процессов, в результате которых он создается, гораздо больше. Яркий пример – счет покупателю, понятная стройная форма документа с четким и конечным набором данных, но что ей предшествует, какая масса вопросов должна быть решена в системе, чтобы счет покупателю был выставлен не в убыток, вовремя и с нужной рентабельностью, здесь все очень сильно зависит от процессов, происходящих в компании. И именно поэтому автоматизация бизнес-процессов гораздо сложнее автоматизации документооборота.

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

 

Так почему же подход «от бизнес-процессов» так редко встречается на отечественном ИТ рынке? Ответы ниже:

  1. Во-первых, к этому подталкивают сами компании, требуя подешевле, в то время как процессный подход (назовем его так) требует объективно больших временных и ресурсных затрат со стороны вендора, т.е. проект разработки и внедрения «процессной» информационной системы будет объективно дороже и дольше.

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

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

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

  5. В-пятых, неготовность компаний к полноценному проекту по адаптации и внедрению отраслевого решения под их особенности, т.к. стоимость подобного проекта в разы превышает стоимость программного продукта, на основе которого он строится.

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

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

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

Инфографика -сравнение областей применения учетной и процессной систем

Чтобы подтвердить наличие и неизбежность тренда управляющих ифнормационных систем , можно, например, посмотреть в сторону так называемых WMS-систем (системы управления складом), которые полностью управляют процессами размещения и подбора товара на складе, выдают задания погрузочной технике персоналу и т.д. WMS-системы уже давно функционируют на процессной парадигме и действительно являются управляющими системами.

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

7 Comments

  1. panvartan

    7. В-седьмых, практически этого никто не умеет делать.

    Reply
  2. ivanov660

    Соглашусь с автором. Существующий подход на рынке и в головах от документов. Но к сожалению большинство текущих решений на 1С также от документа, есть гибридные полу решения.

    Reply
  3. sedata

    Умеем, только вот клиенту продать все это ен умеем…

    Reply
  4. panvartan

    (4) AndreLed, Вы перечислили трекеры, которые планируют перемещения автотранспорта и отчасти водителей. А перемещение запчастей, топлива, денег, документов? Системы исходят из предположения, что эти ресурсы неограниченны?

    Reply
  5. MultiGenius

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

    Reply
  6. sedata

    (4) AndreLed,

    Работаю — в SeaData (.ru).

    Статья болей части касается логистических операторов и международных экспедиторов, а не перевозчиков. Как раз они в совю очередь на определенное плечо перевозки этих самых перевозчиков нанимают. Разные задачи — и решения поэтому разные.

    Reply
  7. rstmx

    Да, указанные автором особенности препятствуют как развитию компаний потребителей услуг ИТ, так и компаний поставщиков ПО, компаний осуществляющих услуги по внедрению.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *