Современные проблемы и намечающиеся тенденции автоматизации транспортно-логистических компаний. Взгляд неоавтоматизатора на существующие на Российском рынке парадигмы.

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

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

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

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

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

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

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

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

1. Во первых к этому подталкивают сами компании – требуя по дешевле, в то время как процессный подход (назовем его так) требует объективно больших временных и ресурсных затрат со стороны вендора т.е. проект разработки и внедрения «процессной» информационной системы будет объективно дороже и дольше.
2. Во вторых – процессный подход требует другой проектной технологии, в которой больше проектных этапов и одним из самых главных является моделирование, когда вендор и заказчик прописывают, как будут осуществляться _процессы_ компании с участием информационной системы, ТЗ разрабатывает позже, основываясь исключительно на материалах моделирования.
3. В третьих – от вендора требуется понимание и не шапочное, бизнес-процессов заказчика, понимает отрасли, бизнеса расходов и доходов заказчика, понимание того где заказчик теряет деньги. Согласитесь – это серьезные требования, которые требует от вендора определенной отраслевой экспертизы, которая на ровном месте никогда не возникнет, ее наработка может занимать годы.
4. В четвертых – компании не ставят перед вендорами задачи снижения издержек и повышения рентабельности в результате внедрения информационной системы т.к. даже не подозревают что такое возможно.
5. В пятых – неготовность компаний на полноценный проект по адаптации и внедрению отраслевого решения под их особенности т.к. стоимость подобного проекта в разы превышает стоимость программного продукта на основе которого он строится.
6. В шестых – отсутствие на рынке типовых процессно-ориентированных решения для транспортно-логистических компаний. На самом деле это неправда – и у нашей компании есть подобное решение, называется программный продукт SeaExpediter, в котором воплощен наш процессно-ориентированный подход к отрасли, но мы всегда сталкиваемся с трудностями по донесению до наших клиентов отличий данного решения от других учетных и документно-ориентированных  программных продуктов т.к. по прежнему очень сильны «документальные» стереотипы.

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

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

Небольшая ремарка по нашему программному продукту:

Осознание, что транспортно-логистическим, компаниям необходимо некое типовое решение (программный продукт) который делал бы проекты внедрения быстрее и дешевле (по сравнению с вариантом разработки и внедрения информационной системы с нуля), пришло к нам в 2009г. Мы хотели сделать подобные проекты доступными не только для крупного бизнеса. К тому моменту мы обладали опытом разработки и внедрения заказных информационных систем для данной отрасли (экспедиторские компании, агенты контейнерных линий, операторы вагонного парка и т.п.) Тогда мы действовали как и весь остальной ИТ рынок - разрабатывали и внедряли информационные системы «от документов», также как и остальные участники рынка раздумывали какая из внедренных нами информационных систем может быть представлена нами как типовая. Провели анализ всех внедренных нами на тот момент решений и поняли, что с таким подходом мы ничего принципиально нового рынку предложить не сможем, будем такие как все – поставщики учетных систем !! Далее последовала концептуальная постановка задачи – какие главные цели должен решить тот программный продукт который мы хотим создать? За ответом далеко ходить не пришлось, главное и основное - дать нашим клиентам инструмент повышения рентабельности их деятельности при имеющихся объемах оказания услуг, кратко и емко. Только так мы могли получить долгосрочные конкурентные преимущества. Постановка такой цели – потребовала от нас полностью пересмотреть наши подходы к проектированию и разработке информационных систем, начать не с технического задания на разработку а с моделирования типовых процессов наших клиентов  в предполагаемом программном продукте с учетом поставленной цели, потребовалось по новой взглянуть на бизнес наших клиентов – понять где и за счет чего происходят денежные потери, по каким причинам фактическая маржинальность перевозок меньше планируемой, и, уже исходя из понимания причин непроизводительных издержек, спроектировать функционал системы который позволял-бы их избежать. Программный продукт, который мы позже назвали SeaExepediter, пришлось разрабатывать полностью с нуля, помимо ярко выраженной ориентации на бизнес-процессы пришлось пристальное внимание уделить вопросам взаимодействия внутренних подразделений транспортно-логистических компаний, поскольку большая часть непроизводительных издержек была связана именно с потерей информации или несвоевременным информированием подразделений друг друга. Разработка подобного решения за счет собственных средств была бы вряд тли возможна, если бы нам не удалось привлечь государственный грант на данные работы, который частично сократил наши расходы и сделал эту работу возможной. Нам пришлось проделать очень большую работу,  совершить и исправить ряд концептуальных ошибок, которые мы допустили на ранних стадиях разработки продукта, поскольку аналогов подобного программного продукта на отечественном рынке просто нет, а знакомство с аналогичными зарубежными решениями у меня состоялось только в этом году на международной транспортно-логистической выставке в Мюнхене, где 2-а огромных павильона были отведены только на решения в области информационных технологий.  Признаться, в Мюнхен я ехал со смешанными чувствами, поскольку хотел на опыте зарубежных коллег получить либо подтверждение что мы выбрали правильный путь (не секрет что западный рынок уже прошел все те стадии развития, которые у нас только происходят и очень показателен в плане тенденций), либо  внести существенные коррективы в наш подход, применённый в SeaExpediter.  С большим удовлетворением могу сказать – тот функционал и тот подход и те принципы,  что мы воплотили в SeaExpediter, я увидел и в решениях наших зарубежных коллег. Разумеется, подсмотрел и пару интересных функций, которые мы планируем реализовать в нашем программном продукте до конца года (автоматическая оптимизация транспортных схем перевозок по срокам либо по стоимости с учетом пунктов притяжения/оформления), которые позволят нам с уверенность заявить, что наше решение – на уровне мировых аналогов. 

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

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

Купрашевич Юрий

Директор и продукт менеджер компании SeaData

kuprashevich@seaexpress.ru