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

22.01.16

Управление проектом

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

логистика автоматизация процессов управляющие информационные системы

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2870    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14422    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5911    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4808    0    andironenko    2    

31

Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?

Компетенции и навыки РП Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5431    0    MariaTemchina    28    

22

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2801    0    MariaTemchina    28    

24

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4264    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10806    0    biimmap    79    

75
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. panvartan 22.01.16 21:02 Сейчас в теме
7. В-седьмых, практически этого никто не умеет делать.
+
2. ivanov660 4344 22.01.16 21:07 Сейчас в теме
Соглашусь с автором. Существующий подход на рынке и в головах от документов. Но к сожалению большинство текущих решений на 1С также от документа, есть гибридные полу решения.
+
3. sedata 31 25.01.16 12:46 Сейчас в теме
Умеем, только вот клиенту продать все это ен умеем...
+
4. пользователь 27.01.16 11:08
Сообщение было скрыто модератором.
...
5. panvartan 28.01.16 10:37 Сейчас в теме
(4) AndreLed, Вы перечислили трекеры, которые планируют перемещения автотранспорта и отчасти водителей. А перемещение запчастей, топлива, денег, документов? Системы исходят из предположения, что эти ресурсы неограниченны?
+
7. sedata 31 01.02.16 15:06 Сейчас в теме
(4) AndreLed,
Работаю - в SeaData (.ru).
Статья болей части касается логистических операторов и международных экспедиторов, а не перевозчиков. Как раз они в совю очередь на определенное плечо перевозки этих самых перевозчиков нанимают. Разные задачи - и решения поэтому разные.
+
6. MultiGenius 28.01.16 13:40 Сейчас в теме
Здесь немного по другому получается система документооборота работает. Документы являются не следствием какого-то действия и побуждают к действию. Сейчас сами проектируем и пытаемся переделать свою корпоративную систему под новые бизнес процессы, в результате проектируем от бизнес процессов так как программа должна помогать работать, а не просто учитывать. Например в зависимости от персональных тарифов клиента система должна просчитывать сколько клиенту выставить, а не так, что мы тупо выставили счет и все. + Та же загрузка машины (занимаемся сборниками) где вроде все должно по объему и весу влезть, а на практике приходится что-то отгружать, в результате исходный документ меняется, а подтверждение загрузки уже формируется по факту. И так много где, еще особенно в плане финансов.
+
8. rstmx 02.02.16 12:17 Сейчас в теме
Да, указанные автором особенности препятствуют как развитию компаний потребителей услуг ИТ, так и компаний поставщиков ПО, компаний осуществляющих услуги по внедрению.
+
Внимание! Тема сдана в архив