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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. В-шестых, отсутствие на рынке типовых процессно-ориентированных решения для логистических систем предприятий. На самом деле, это неправда, и  нас  подобное решение которое  называется  DATACore: LMS , в котором воплощен наш процессно-ориентированный подход к отрасли, но мы всегда сталкиваемся с трудностями, пытаясь донести до наших клиентов отличия данного решения от других учетных и документно-ориентированных  программных продуктов,т.к. по-прежнему очень сильны «документальные» стереотипы. Пример подобной попытки - смотрите в разделе процессный подход.

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

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

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

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

 на разработку, а с моделирования типовых процессов наших клиентов в предполагаемом программном продукте с учетом поставленной цели, потребовалось по-новому взглянуть на бизнес наших клиентов – понять, где и за счет чего происходят денежные потери, по каким причинам фактическая маржинальность перевозок меньше планируемой, и, уже исходя из понимания причин непроизводительных издержек, спроектировать функционал системы, который позволил бы их избежать. Программный продукт, который мы позже назвали DATACore: LMS, пришлось разрабатывать полностью с нуля, помимо ярко выраженной ориентации на бизнес-процессы пришлось пристальное внимание уделить вопросам взаимодействия внутренних подразделений транспортно-логистических компаний, поскольку большая часть непроизводительных издержек была связана именно с потерей информации или несвоевременным информированием подразделениями друг друга. Разработка подобного решения за счет собственных средств была бы вряд ли возможна, если бы нам не удалось привлечь на данные работы государственный грант, который частично сократил наши расходы и сделал этот проект возможным. Нам пришлось проделать очень большую работу,  совершить и исправить ряд концептуальных ошибок, которые мы допустили на ранних стадиях разработки, поскольку аналогов подобного программного продукта на отечественном рынке нет, а знакомство с аналогичными зарубежными решениями у меня состоялось только в этом году на международной транспортно-логистической выставке в Мюнхене, где два огромных павильона были отведены только на решения в области информационных технологий. Признаться, в Мюнхен я ехал со смешанными чувствами, поскольку хотел на опыте зарубежных коллег получить либо подтверждение, что мы выбрали правильный путь (не секрет, что западный рынок уже прошел все те стадии развития, которые у нас только происходят, и очень показателен в плане тенденций), либо внести существенные коррективы в наш подход, примененный в DATACore.  С большим удовлетворением могу сказать: тот функционал, тот подход и те принципы, что мы воплотили в DATACore, я увидел и в решениях наших зарубежных коллег. Разумеется, подсмотрел и пару интересных функций, которые мы планируем реализовать в нашем программном продукте до конца года (автоматическая оптимизация транспортных схем перевозок по срокам либо по стоимости с учетом пунктов притяжения/оформления), которые позволят нам с уверенность заявить, что наше решение – на уровне мировых аналогов.  

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

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

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

Генеральный директор

компания SeaData