Комментарии 28
Давайте честно, ERP создана для учёта документов и денег. ....
Давным давно, в прошлом веке, автоматизация (по современному наверное правильнее говорить цифровизация) бизнесов велась по методу "островков автоматизации". Это когда отдел кадров имел полностью свою автоматизацию, бухгалтерия свою, склад свою, и т.д..
Такой подход был осужден и заклеймен на Западе уже в 80-е годы (тогда автоматизация/цифровизация бизнесов велась не на ПК, а на мэйнфрэймах). И тогда появился термин ERP и появилось множество продуктов под эту парадигму.
Идея их, да, была построение в единой программной архитектуре многомодульного продуктоа с охватом стольких функционалов на сколько хватало сил, средств и потребности заказчика.
Но уже с самого начала разные ERP стали позиционироваться с уклоном в какой-нибудь конкретный вид бизнеса. Например, SAP ориентировалась на баизнесы с так называемым "непрерывным" производством. Это химия, металлургия и т.п. ERP (нынешнее ее название Asset Suite, а изначально называлась Passport), с которой я как DBA проработал 20 лет, позиционировалась в ядерную энергетику.
Кроме такой ориентации также была различная ориентация в смысле системной и программной платформености. SAP изначально использовали IBM mainframe и их OS - MVS (SAP была основана пятью сотрудниками, работавшими в ИБМ). Вскоре их продукт был перепозиционирован на платформу Unix.
Кроме того SAP программируется на основе собстенного языка и собственной базе данных.
По другому пути пошли создатели Asset Suite. Язык был взят стандартный - Кобол, база данных DB2, сервер приложений - CICS.
Довольно длинное получилось введение. Перехожу к сути моего комментария.
ERP, это не про "документы и деньги" как Вы пишите. Это про все что может быть нужно бизнесам. Главное в ERP это стандартный подход к построению комплексной системы управления (вот правильный термин) бизнесов во всех его проявлениях.
Единство базы данных, программной среды и интефейса это сильнейший аргумент в пользу ERP. Доработки модулей из коробки абсолютно возможны практически с любой из известных ERP (немного напрягает SAP из-за уникальности их языка и БД, но и они уже давно позволяют по крайней мере использовать разные стандартные базы данных).
Качество доработок, конечно, может быть разным, от непригодного до идеального. Принципы ERP нисколько этому не противоречат, поскольку вне зависимости от функционала это всегда было, есть и будет информационная задача с общими для всех их подходами и результатами. Складское хозяйства исключением не является.
Да, конечно, за много лет работы именно со складским хозяйством в Вашей компании накопился огромный опыт и Вы его воплотили в Вашем продукте. Но тоже самое можно было бы сделать в рамках любой ERP системы.
Пусть у Вашего продукта есть API к нему. Ну и кто и как должен их использовать чтобы интегрировать Ваше Складское Хозяйство в имеющуюся у бизнеса ERP XYZ? Смогут ли они сделать это так же красиво как Вы сделали Ваш продукт? А Вы сможете им помочь в этом?
У меня есть пример той компании где я работаю. Их ERP системой в плане доработок стандартных модулей под потребности бизнеса занимается внешняя компания. И он это делает не только для нас, но и других похожих по бизнесу. У них конечно есть наработки, но они в рамках общей архитектуры ERP.
Так что основая идея статьи очень даже располагает для критики. Не надо ходить по кругу и водить пользователей за сабой.
Сказав это я чисто по человечески желаю Вам и Вашей компании успехов и багополучия.
Для начала, хочу заметить, что это явно рекламная статья, а на Хабре их пишут не для того, чтобы читать под ними комментарии и уж, тем более, на них отвечать.
Думаю, что не стоит путать производственный склад и, к примеру, склад маркетплейса. Это две большие разницы. Ну и если ERP содержит в себе модуль MES, то его тоже зачастую выносят отдельно, подцепляя к WMS. Все по той же причине: куча мелких онлайновых операций/транзакций, которые ERP не нужны. Если все свалить в кучу, то зачастую получается гибрид онлайн и офлайн обработки, который ни к чему хорошему не приводит. А ERP от WMS нужны складские остатки, причем зачастую не онлайн, а срез на дату/период.
Вопросы по API не понял. Если уж там есть разработчики, которые теоретически могут WMS запилить, то уж интегрироваться с внешней системой они точно смогут. А вот разработку WMS с нуля я бы не рекомендовал делать, тут я с автором согласен.
Если что, я больше 15 лет проработал с разными WMS, в основном дистанционной торговли, но сталкивался и с производственными. И даже как-то написал свою, правда очень маленькую и примитивную времянку.
Ну и если ERP содержит в себе модуль MES, то его тоже зачастую выносят отдельно, подцепляя к WMS. Все по той же причине: куча мелких онлайновых операций/транзакций, которые ERP не нужны.
В ERP (если это ERP) может быть и на самом деле есть масса других модулей с "кучей мелких онлайновых операций/транзакций, которые ERP нужны".
Какие вообще могут быть ограничения на ERP если по определению это то что предназначено для полного покрытия нужд бизнеса по управлению им. И финансовые функции и управление персоналом и складским хозяйством и много чего еще.
В ERP, которое я как DBA и системщик поддерживал 20 лет как раз не использовался финансовый модуль (хотя он там есть), но были использованые разные другие модули с самыми разными характеристиками, включая складское хозяйство, наряды на работы, учет опасных материалов и еще с чем я за 20 лет даже и не сталкивался, и включая пакетные заданиями генерирующими отчеты.
В России видимо другие представления об ERP системах, ну и еще это то что в моем случае ERP выполнялась на ИБМ мэйнфрэйм. Сейчас это же ERP выполняется в облаке кучей серверов в то время как рашьше на небольшом, можно даже сказать весьма маленьком МФ. На серверах х86-64 это делать проблематично, но кучей серверов тоже можно.
Что касаемо API. А Вы уверены что интегрирование "с внешней системой" не своей WMS будет проще чем написать свою WMS в своей "внешней системе", в которой есть какой ни какой зародыш WMS? В нашем случае так и было сделано. Внешней компанией сделано, хреново сделано. Но было в итоге отрихтовано и проработало много лет. Модули из SAP тоже переносились в ERP Asset Suite.
Тут важно понимать теорию. А согласно теории чем больше включается в единый комплекс тем меньше издержек на интеграцию новых функционалов (модулей), тем меньше раноплановых специалистов и легче поддерживать компетенцию разработчиков или эксплуатантов.
А если сшивать ИТ бизнеса из кучи раномастных функционалов сделаных совершенно по разному с разными заморочками разных вендоров (а их может быть в нынешней ситуации в ИТ бесконечное множество, и оно постоянно растет) то это еще тот челендж и бардак. Тоже имел опыт таких подходов. Несмотря на то что, как могло показаться из вышесказаного, у нас вроде как есть ERP, но все таки есть куча разномастные, внешних к этой ERP, модулей с интерфейсами к ней. И это настоящее горе. Но мы как те ёжики. Не я лично конечно. Я это со стороны наблюдаю.
опять споры по микросервисы vs монолит
Вы же сами пишете "выполняется в облаке кучей серверов". Т.е. действительно разносится система на разные сервера не зря, верно? Допускаю, что существуют процессы, которые в ERP будут именно с мелкими отдельными транзакциями, но вряд ли это будет ERP, которой WMS нужна, если это не ERP муравейника.
Если система (в данном случае WMS) изначально заточена под интеграцию, то проблем именно с интеграцией не вижу. В принципе, все серьезные системы под интеграцию заточены. Кстати, если уже есть хороший API со стороны одной системы, то разработчикам отвечающим за другую в разы меньше головной боли, чем если бы пришлось с нуля интеграцию разрабатывать, хоть бы они и обе системы контролировали. Те люди, которые написали WMS уже хорошо знают, что надо и как надо, говорю из собственного опыта. Работал в одной довольно крупной фулфилмент-компании, когда приходил, порядковый номер клиента (ID-шка в БД) ,была порядка 400, когда уходил - была более 800. Не всем, конечно, была нужна интеграция по API и, наверное, каждый 10-й только хотел что-то такое, что у нас не было (больше по процессам, чем по API), но опыт позволяет мне говорить, что не будет проблем с интеграцией.
Вы же сами пишете "выполняется в облаке кучей серверов". Т.е. действительно разносится система на разные сервера не зря, верно?
В нашем случае, однако, несмотря на то что в облаках только кучей серверов можно выполнять сколько нибудь нагруженные системы (а очень нагруженные системы кучасми куч), БД ERP системы стоит на одном сервере.
Это изначально была централизованная БД на мэйнфрэйме и изменять это вендор не стал или не смог. Куча серверов в нашем случае это сервера приложений выполняющих бизнес логику (до перехода в облако это все размещалось на том же и единственном МФ вместе с БД) ERP системы и дополнительные примочки к этой ERP навроде обсуждаемой здесь WMS, которая до перехода в облако тоже выполнялась на МФ c ERP модулем подкудрявленным для специфики нашей компании.
Допускаю, что существуют процессы, которые в ERP будут именно с мелкими отдельными транзакциями, но вряд ли это будет ERP, которой WMS нужна, если это не ERP муравейника.
Любая компания если это не ларек имеет некий набор функционалов общих для всех. Отдел кадров, бухгалтерия, снабжение/сбыт, тот же склад, охрана, и конечно же управление собственно процессом бизнеса, каким бы он ни был. Причем коль скоро это единый организм, то есть связь между всеми службами. Т.е. по сути ИТ должна быть централизованной, а не распределенной чтобы точнее отражать сущность цифровизируемого объекта.
Проблема коротких и длинных транзакций это проблема выбранной платформы. Да на х86 (даже с -64) решение этой проблемы (как впрочем и любой другой проблемы) состоит в разнесении ИТ на много серверов. По сути это давно уже стало навязчивой идей архитектеров ИТ. Они не умеют мыслить в терминах централизованых решений. И это идет не из реальности, а из мэйнстримовского понимая ИТ что оно должно быть обязательно распределенным. Это прет из всех щелей. Особенно это драматично происходит в России, где возможности использовать иные чем х86-64 платформы просто нет. И не потому что санкции, это родовая травма российского ИТ, которое перерождалось в 90-е годы в условиях экономического колапса. Другие страны этого не проходили и в тамошных ИТ есть больше гибкости и вариативности.
В принципе, все серьезные системы под интеграцию заточены. Кстати, если уже есть хороший API со стороны одной системы, то разработчикам отвечающим за другую в разы меньше головной боли, чем если бы пришлось с нуля интеграцию разрабатывать, хоть бы они и обе системы контролировали.
API это не про интеграцию. Это про затыкание дыр. Интеграция это когда вся система ERP (или любая другая ИТ-шная система, например пенсионная система, система ГАИ, здравоохранения и т.д и т.п.) строится на унифицированных подходах и средствах. По факту так сложилось что в ИТ во-первых, есть множество аналогов одной и той же функционфльности, и как результат во-вторых, множество прикладных поделок (возможно идеальных каждая по отдельности как обсуждаемая здесь), но, скажем так, проблематично объединяемых (интегрируемых) во что-то целое.
Вы можете представить "ERP" систему созданную с нуля "интеграцией" модулей от разных вендоров, использовавших разные подходы к программированию, системам, БД и т.д.? Пристегнуть эту WMS к 1С, используя API может быть и можно, но это еще не все. Наверняка что-то еще может понадобится кроме склада и что не ахти как реализованно в 1С. Да и этом WMS, несмотря на большой опыт ее разработчиков в складском учете, для какого-нибудь пользователя найдется изъян. А в большенстве случаев пользователям будет не нужно многое что есть в этом WMS.
Это жизнь.
API это не про интеграцию. Это про затыкание дыр.
Я бы назвал это ересью, если бы это не было просто ерундой.
Про пропаганду мейнфреймов могу сказать то же самое.
Ну и про то, что вся ИТ индустрия ошибается, переходя на с мейнфреймов на модульную инфраструктуру - это, конечно, вообще очень сильно.
Ну и про то, что вся ИТ индустрия ошибается, переходя на с мейнфреймов на модульную инфраструктуру - это, конечно, вообще очень сильно.
Не вся ИТ индустрия, а только российская.
Если бы на самом деле все переходили то уже никаких МФ в природе бы быть не могло. Как многие другие платформы, которые были да сплыли. Но они есть и даже очень есть.
Настолько есть что весной этого годы появилось новое семейство Z - z17. Это Вам о чем-нибудь говорит? Думаю что нет.
Ну, почему же. IBM'овская серия Z мне известна. Вопрос только, где и как она применяется. NASA, насколько мне известно, отказалась от использования мейнфреймов больше десяти лет назад. Видимо не хочет продолжать сидеть на знаменитой фишке IBM, когда мейнфрейм продают в готовой максимальной конфигурации, но с частью неработающих процессоров, которые потом просто включают за дополнительную плату.
То что Вы написали очень точно описывается поговоркой: "Слышал звон, да не знает где он".
Я в одной из моих статей это достаточно подробно описывал чтобы не повторять небылицы.
Повторю вкратце. Когда покупается МФ то платится за все что в нем. Есть несколько физических конфигураций. Их немного.
А вот оплата лицензии за классическое ПО зависит от активированных ресурсов CPU и память, и на каком уровне активировано. Уровней очень много.
Если МФ покупается не для z/OS то ресурсы активируются на максимальном уровне. И лицензии на софт рассчитываются по количеству CPU.
Предлагаю Вам, прежде чем Вы публикуете Ваши домыслы про МФ, посылаь их мне в личку для редактирования и корректировки.
Не понял, в чем разница между "включить процессор" и "активировать вычислительный ресурс". Те же яйца, другой профиль.
Предлагаю Вам, прежде чем Вы публикуете Ваши домыслы про МФ, посылаь их мне в личку для редактирования и корректировки.
Посмотрел глубоко заминусованные статьи про мейнфреймы и решил, что не буду этого делать.
Вы правы, статья по определению рекламная, поскольку выложена в корпоративном блоге компании. Но это не делает информацию из неё бесполезной или меня безучастным. Я читаю комментарии и отвечаю на них, пока на все комментарии времени не хватило даже вычитать. Мое основное утверждение в статье — имеют место оба подхода, но в 90% случаев из тех, кому реально нужен функционал WMS, лучше внедрить отдельным решением. Соглашусь по поводу MES, там, где это необходимо, тоже часто выносят в отдельное решение.
Спасибо за пожелания. Вы правы, весь функционал можно реализовать в рамках ERP. И мы этим, как интеграторы, тоже занимаемся, и это тоже наш хлеб. Но всегда ли это оправдано с технической, финансовой и бизнес точек зрения? Статья как раз об этом, что прежде чем выбрать путь, нужно очень хорошо оценить риски, ресурсы, сложность, внутренние компетенции, в идеале — провести профессиональный аудит внешний и т. д.
С API и интеграциями, естественно, мы помогаем, как и любой серьезный интегратор. Для 1С, например, у нас вообще есть полноценная официальная интеграция готовая.
Говоря про «ERP — это про деньги и документы», мы не говорим об общей концепции, больше о реалиях российского бизнеса. С вашим опытом вы должны согласиться, в 90% случаев в России это про документы, деньги и ресурсы. Это практически весь малый, средний и часть крупного бизнеса.
Мой опыт в СССР/Россия это 80-е и начало 90-х. Он закончился в конце 90-х. На тот момент, кстати, я поддерживал 1С в торговом доме челябинского трубопрокатного завода. Устанавливал, изменял под запросы бухгалтерии. Тогда 1С был еще про деньги.
Мой опыт последих 25 лет это канадское энергитическое предприятие с 10 000+ работников и миллирдными оборотами, которое с середины 90-х уходит с МФ (до этого у них все было на МФ, а теперь почти все в облаке), и буквально вчера я передал последнюю БД в облако.
ИТ этого предприятия имеет две ERР класса системы и кучу разномасный модулей худо-бедно интегророванных между собой и с ERP. Плюс много бла-бла-бла про контейнерные приложения и AI. Только что отказался от трэйнинга в Микрософт навязываемого нашим ьенеджером. Пугает что те кто откажется "отстанут". Мне в мои 70 и не надо никого обгонять уже. Я и так в некотором смысле впереди многих.
Тем не менее я продолжу утверждать что ERP, последнее врямя также говорят про Assets Management, это изначально интегрированная система, включающая в себя по возможности все потребности в управлении бизнесом и которая состоит из модулей созданных на унифицированных подходах и средствах. А интегрировать то что сделано на разных подходах и средствах это иммитация интеграции. API не палочка выручалочка, а отмазка.
Напишите ещё статьи "Молоток vs Пассатижи" , "Чемодан vs Телефон", "Зелёнка vs Пенициллин" и т.д.
1C тащем-то это как раз очень даже про склад - насколько я помню, их решение с регистрами со времен семёрки оченно даже котируется.
вообще, подтверждаю, что при сшивании разномастных систем ERP и WMS, часто получается бардак с постоянным прокидыванием туда-сюда обмена и вечными доработками. Объем доработок небольшой только на первом этапе интеграции двух (и более) систем, а потом начинается - любые изменения в процессах требуют допиливать сразу две системы, постоянно выясняется, что тут не учли, там надо доработать, и так далее. Не видел ни одного случая, когда хватало коробочных решений как для ERP, так и для WMS, в результате представление, что за полтора месяца интеграция и доработка будет сделана на WMS-ной коробке - это просто рекламный обман клиента, не более.
Только в стране розовых пони бывают такие сроки, которые указаны в табличках. Такой безудержный оптимизм излучают только менеджеры по холодным продажам, и то если их начальство перед выходом к клиенту зарядило коньяком. Реальность суровей.
Своим опытом практика клянусь- не надо верить этим красивым таблицам, там все сроки занижены в 2-3 раза минимум, затраты преуменьшены кратно. Я участвовал в проектах, где интеграция шла более года. Да, перекинули технически за полтора месяца, а перед этим 4 месяца согласовывали и пилили доработки, потом после этих полутора месяцев, когда вылезли критические недоработки, еще 7 месяцев вжикали напильником. Казалось - сшили вместе коробку с готовым решением, и все, а в реальности решение не готово.
Относительно невозможности собрать требования для доработки ERP - это миф. Как раз работники, вовлеченные в процессы, гораздо лучше знают, что конкретно им требуется, и великолепно смогут описать это IT, потому что проблемы все выстраданные, а не надуманные внешним аналитиком, который берется интегрировать системы. Вот, например, у меня документ обследования лежит - там аналитическая часть WMS вообще отсутствует как класс. То есть, аналитик даже не поинтересовался, какими аналитическими инструментами пользуются люди, какими не пользуются, какие существуют, какие требуются. А на практике - выгружай голые списки из регистров, и своди в эксельке, если хочешь банально узнать, сколько в среднем хранится та или иная номенклатура по месяцам. Начальник склада годовую загруженность считает по точкам (в смысле, выгружает количество паллет на момент - например, на начало месяца), а на уточнение, что у него 30% паллет приходят и уходят одними сутками - он татарин, выразился лаконично: "кысмет"... В одной WMSной коробке вообще не было аналитики объемов движений товара - только выработка сотрудников. А там, где выработка не регистрируется - считай опять из регистров :)
В случае с доработкой также возможно пропустить часть операций и этапов, которые в коробку WMS заложены - например, у меня на предыдущей работы процесс размещения в коробке принятого выглядел так: кладовщик брал товар из ячейки приемки на себя, а потом прибивал к ячейкам перемещениями. Но в ситуации, когда он раскладывает 500-600 позиций за раз, "взять на себя" занимало до 1-2 часов непрерывного сканирования. "Взять на себя" хорошо работает, когда монопаллет несешь или 20-30 номенклатур. А когда их 500, и все умещаются в коробочку 50х50, то выполнить все, что в WMS ПРЕДПОЛАГАЕТСЯ ПО ДЕФОЛТУ, жрет время. В результате потребовали упростить процесс - я глянул, что можно поменять, а там в WMS все прибито гвоздями, документ перемещения на кладовщика никак не обойдешь - он пишет в регистр, а при перемещении оттуда списывает, в результате изгалялись, делали автоматическое формирование и выполнение перемещений на кладовщика по событию и размножили кратно ячейки приемки, чтобы 1 ячейка=1 коробка. Этот вариант был самый экономный, а неэкономный - это переписывать вообще весь процесс перемещений и размещений товаров.
И вообще, по практике, от 30 до 50% функционала WMS не используются, так как не подходят под бизнес-процессы. А процентов 20 функционала дописывается даже при достаточно простых внедрениях. Коробка готового продукта используется, когда нет ресурса дописывать или если не хотят слететь с поддержки. А когда ресурс есть, и поддерживают самостоятельно - то возможны варианты, и дописать имеет смысл, так как позволяет внедрять изменения постепенно, исправляя и подпиливая под требования процессов. Я видел весьма успешные и рабочие дописки WMS-модуля в ERP. Относительно рисков типа "бухгалтер повесит работу склада" - обмен между системами рисков несет как бы не больше. Я на одной работе чуть ли не по раз 10 в день "толкал" обмен, потому что в журнале обмена постоянно то ошибки, то подвисало, то просто пока обмен по расписанию отработает, объект на мастере удаляют (например, документ откатили для изменений), и пошли расхождения. Риск при доработке ERP есть только когда команда поддержки системы очень маленькая, а изменения отвратительно документированы - тогда разработчик становится уникальным специалистом, и держит компанию за горло. Но, с другой стороны, встречал таких уникальных специалистов, сидевших и тупо на самописных сервисах обмена, в которых, кроме них, не разбирался никто.
Итоговый чек-лист - это просто обман клиента. Программно обработка 500 SKU ничем не отличается от обработки 5000 SKU, и даже 600000 SKU - тупо справочник раздувается, а склад в 2000 метров по структуре ничем не отличается от 15000. Я видел склады с 6000 ячеек на 600 метрах и на 12000. И видел сложную вложенность ячеек для склада из нескольких ячеек напольного хранения и одного стеллажа для фурнитуры, вот там я поломал голову, как воткнуть такую топологию в WMS. И на погрешность инвентаризации вопрос, внешняя ли WMS или ERP не влияет НИКАК. Я делал на 99,6% сходящуюся инвентаризацию на складах под управлением ERP с 15000 SKU и было, что для склада с 300 SKU выходило 76% (потому что в коробке WMS процесс канбана упаковки на производства вообще работать не мог, так как не был заложен, и даже архитектура не давала написать, и все отгрузки шли по распечаткам из экселя). И работал с самописными модулями инвентаризации, гораздо более продвинутыми, чем в любой коробке (например, циклическая инвентаризация в коробке ни у одной 1С-ной WMS не присутствует, или например, принцип DIY-инвентаризации, когда результат не влияет на остатки без отдельной человеческой проводки - можно сделать просто просчет для технических нужд склада).
Либо тот, кто писал эту статью, на складах никогда не работал, либо сознательный обман.
Очень интересное мнение, оно одновременно имеет под собой логическое обоснование со стороны ИТ и подтверждает мое мнение, что логистикой в первую очередь должны заниматься эксперты в логистике и бизнесе, а не ИТ-специалисты или экономисты. Действительно, для 500 и 5000 SKU разных требований с точки зрения хранения данных о них нет, но склад с 500 SKU и склад с 5000 SKU — это два разных склада. В первом, возможно, вообще автоматизация не окупится, если не планируется рост, во втором, скорее всего, окупится за счет повышения эффективности, снижения % ошибок и т. д. Склад в 2000 метров и в 15000 метров зачастую отличается размером бизнеса и количеством сотрудников. Что говорит, например, о наличии необходимых ресурсов на автоматизацию и точек роста эффективности. Да, будут исключения из правил, например, небольшие фармакологические склады с дорогостоящей продукцией и сложными процессами, где необходима WMS, но их можно свести в погрешность. Как и склады 15000+ метров с 2 SKU, например, цемента, лежащего в мешках на паллетах, и продажей прям паллетами — не нуждаются в WMS. Но это все исключения.
По поводу сроков и розовых пони. Это реальные и проверенные не на одном проекте сроки и стоимости. С момента согласования ТЗ и с учетом грамотного изначального аудита склада, это более чем реальные сроки внедрения, которые приведут к улучшению показателей. Конечно, после первоначального внедрения будет проводиться качественная продуманная доработка проектной командой под изменяющиеся потребности бизнеса. Процессы и технологии меняются, и автоматизация должна быть процессом постоянным. Но эффективное первоначальное внедрение укладывается в эти сроки. Вы клянетесь своим опытом, но сколько внедрений в год вы делаете? Судя по тексту, вы штатный специалист. А значит, это одно внедрение раз в несколько лет (если работу меняете). Мы делаем 15+ внедрений в год. Да, бывают долгие, но бывают и быстрые.Цифры средние.
Вы не поняли Ивана. Он про другое говорил.
... подтверждает мое мнение, что логистикой в первую очередь должны заниматься эксперты в логистике и бизнесе, а не ИТ-специалисты или экономисты.
Странное утверждение. Во-первых не понятно объединение ИТ-специалистов и экономистов.
А во-вторых, приведу пример из моей небогатой практики бизнес программирования.
Случилось мне работать в начале 90-х в одном большом металлургическом заводе с примерно 30 000 работников. Был я тогда зам. нач. отдела АСУП (кто не знает это Автоматизированные Системы Управления Предприятием) по разработке. Охват автоматизацией тогда был не велик и я был озабочен расширением этого охвата. Сначала взгляд упал на Отдел Кадров, потом на Отдел Научной Организации Труда, который по факту занимался штатным расписанием.
Взял я программистку из отдела и пошли мы к "экспертам". Встретили нас две сотрудницы заранее предупрежденные о нашем посещении. Радушно нас встретили, разложили образцы их документации, и рассказали как работает штатное расписание в их бумажном исполнении.
По ходу их рассказа я задавал вопросы и рассказывал как это могло бы быть воплощено на компьютере (не ПК, а настоящем компьютере, который у нас тогда был. Даже два, двухпроцессорных, 32 МБ, 20 ГБ дисков (second hand из Европы на самом деле. Конец 70-х начало 80-х в США), с Системой Виртуальных Машин - IBM VM/SP, настоящая реляционная БД IBM SQL/DS, QMF, REXX, ISPF и куча другого софта от IBM, включая OS/2. 1994 год!).
К концу рзговора одна из двух сотрудниц ОНОТ говорит другой: "Слушай, Маша, а ведь у нас бардак и нам надо сначала навести порядок и лишь потом "автоматизироваться". Я оттуда вскоре ушел, но та программистка еще много лет работала с ОНОТ и ОК и писала для них программы и они внедрялись.
Знал я и другого программиста, который писал программы для бухгалтерии "конфетной фабрики" (так он называл своих заказчиков). Он знал бухгалтерию лучше тамошних бухгалтеров и много им помогал в собственно бухгалтерии.
Так что не знаю про экономистов, но ИТ-специалисты, в виду их уникальных способностях в области обработки информации (а именно этим занимается ИТ), очень даже могут помочь и в логистике и в управлении бизнесом. Не все конечно, но уникальность в этом есть точно. И ей не надо принебрегать.
просто вот мой послужной список:
2001-2003 - сотрудник склада (FEDEX)
2003-2007 - менеджер склада (склад один, но 2 перешивания склада на разные ИС, 2 внедрения с разными клиентами)
2007-2016- менеджер по логистике (свои склады, разные организации, но ничего не внедрял, по счастью)
2018-2022- инженер по стоку и складским операциям (4 склада, внедрения)
2023-2024 - администратор WMS (две работы, 9 и 1 склад, внедрение)
2024-2025 - технолог СУС (1 склад, доработки после внедрения)
Вы кичитесь своим опытом в логистике вообще не подозревая, что опыта в логистике у меня побольше вашего. Относительно "количества внедрений" - с 2018 года я ежегодно что-то крупное внедрял, но между мной и вами есть небольшая разница - "внедренцы" со стороны поставщика ПО пару месяцев поскачут по складу туристом и убегают, А Я ОСТАЮСЬ, и гребу лопатой все то, что вы просто не видите, не знаете, или на что вам сугубо наплевать, так как вы деньги получили :)
Да, будут исключения из правил, например, небольшие фармакологические склады с дорогостоящей продукцией и сложными процессами, где необходима WMS, но их можно свести в погрешность.
вообще, с развитием маркетплейсов мелкие склады с большим количеством номенклатур - это скорее правило, потому что маркетплейсы на схеме FBO/FBS перекладывают на поставщиков большую часть складской обработки, и как раз основная масса заказчиков именно такие склады и внедряет. Производственники обычно работают с несколькими сотнями SKU, но, как правило, у них все внедрено до вас. Вы свели в погрешность почти полрынка внедрения WMS :) специалист, нечего сказать. Или просто у вас выборка такова, потому что ценник на ваш продукт конский, и большинство его просто не тянут.
С момента согласования ТЗ и с учетом грамотного изначального аудита склада, это более чем реальные сроки внедрения, которые приведут к улучшению показателей. Конечно, после первоначального внедрения будет проводиться качественная продуманная доработка проектной командой под изменяющиеся потребности бизнеса.
рекламное бла-бла-бла общими фразами. А на практике - аудит всегда поверхностен (потому что в такие сроки практически невозможно его сделать подробный - люди банально не вспомнят целый ряд операций и возможных ситуаций - например, вопрос об отрицательных остатках на обмене впервые всплыл через полгода, обнаруженный случайно - просто обращений к этим номенклатурам не было, а там весь обмен криво работал), постоянно всплывают вещи, пропущенные аудитом, за время внедрения выплывает необходимость доработок и переработок, даже хорошо отлаженные на тестах процессы на проде оказываются не тем, что предполагалось, даже без изменения бизнес-процессов, я примеров могу накидать массу. Время на отслеживание качества и поддержку прода дается минимальное - Акселот дал 2 недели работы сотрудника после переливания на прод, Ситек - месяц (и это для крупного предприятия с 14 складами и 8 заводами, я был удивлен, что они согласились - видимо, тоже в уши надули, что все будет быстро, но даже через год после того, как я уволился, они фактически проект не закончили), Бит поддерживал две недели, и плюс месяц по допсоглашению, и все равно на складе в 600 метров налажал - я через год с лишним разгребал все, что там не было донастроено и доработано, в последнем случае даже ABC-анализ из коробки не работал корректно, они его просто откатили "до лучших времен", так и осталось на два года. После того, как сотрудник "внедренца" со склада убегает, достучаться до техподдержки бывает достаточно нетривиальным делом, я отдельно у себя документировал все общение с ТП Акселота, потому что иначе я просто не мог доказать начальству, что я не игнорирую проблемы, а ежедневно трачу на ТП по часу в день и более.
Т.е. количество внедрений ваше ничего не говорит о КАЧЕСТВЕ. И не надо опять рекламной болтовни, что ваши клиенты довольны - все понимают, что отрицательные отзывы о вашем продукте и работе вы никогда и никому не покажете. 15+ внедрений в год - получается. что на специалиста приходится менее одного месяца разобраться во всем и все сделать. За это время нельзя даже въехать в суть бизнес-процессов. Я как-то с топологией разбирался месяца два (правда, по 8 складам, но все под единой системой) - но качественно нарисовать топологию занимало на склад не меньше недели, у меня каждый день начинался с проверки схем со складскими работниками, и каждый раз находились какие-то дополнения, изменения и прочее. А ведь я на этом предприятии со складами уже 8 месяцев проработал, аналитику делал, обследования. И все равно постоянно вылезало то, что не было учтено. Доходило до того, что как в фильме ДМБ " Пока противник рисует карты наступления, мы меняем ландшафты, причём вручную. " Реально - вчера я согласовал вылизанную схему, вечером залил, а ночью начальник смены добавил балок, с утра началась работа, и на проде физически груз не лез в ячейки.
15 внедрений в год - это типичное ТЯП-ЛЯП И В ПРОДАКШН.
Но эффективное первоначальное внедрение укладывается в эти сроки.
вранье - в эти сроки укладывается только техническое внедрение перерисовать топологию, залить НСИ, сделать основные настройки, прокинуть обмен, настроить периферию и залить конфигурацию. Но это только верхушка айсберга. А в реальности все гораздо дольше и сложней, но это "дольше и сложней" продается плохо - вы рисуете заказчику потемкинскую деревню и убегаете к следующему.
Да, бывают долгие, но бывают и быстрые.Цифры средние.
средняя цифра в 1,5 месяцев означает, что если для одного из 15 затягивается на год (что по практике не редкость), то у остальных должно быть по месяцу, а если еще хоть у одного полгода, то остальные должны внедряться за три недели :) Ага, внедряете за миллисекунду, все верят.
PS.Почитал про WMS, которую вы рекламируете - в лайт версии вообще вырезана половина стандартного функционала, без которого будет работать разве что ремонт обуви дяди Васи на рынке в Урюпинске (например, маршруты подбора, FIFO,LIFO etc). У вас там вообще какой-то треш. Вы позиционируете продукт Lite как продукт для мелких складов и вырезаете из него погрузку навалом, которым на мелких складах в значительной степени и отгружают (например, на одном складе использовали виртуальные паллеты, чтобы отгрузить, а список физических мест и количества сводили в эксельке - ну не лезет паллет в ларгусы. которыми развозили по клиентам). Аналогично вырезано пополнение и работа с партиями С головой у вас в компании точно все дружат? Мелкий склад не значит, что не работает с партиями и характеристиками. Впрочем, судя по опыту моих собеседований в компании-интеграторы за последние три месяца, у меня сложилось впечатление, что к вам берут только сильно контуженных, а специалистов с опытом "на земле" вам не требуется, ваш бизнес - не решить проблемы клиента, а продать продукт, соответственно, проблемы эти для вас - лишь досадное препятствие к вожделенной оплате счета, и вы их просто обходите. Поэтому вряд ли вы мою т.з. вообще поймете.
P.P.S. в списке проектов половина - "поставка терминалов", то есть, купи на али терминал и продай заказчику. Суперпроект года. Таких "проектов" любой продажник может по десятку в день запилить :)))
Иван, вы пытаетесь судить всех по одной гребенке и отрицательному опыту внедрений и работы с несколькими интеграторами. Очень жаль, что у вас сложилось такое мнение об интеграторах в общем. От того же «Акселота» мы отличаемся как раз персонализацией подхода, гибкостью продукта, более адекватным ценником и скоростью внедрения. Странно судить о компании, её подходах и качестве работы без опыта сотрудничества с ней. Если будете внедрять на текущем или новом объекте — обратитесь к нам, посмотрите на подход, пообщайтесь с экспертами, сделаете объективные выводы и мы их с удовольствием обсудим и учтем. Пока же вы субъективно нам приписываете грехи других компаний и собственного неудачного опыта с ними. Не хочется в полемику уходить. Отвечу на основные тезисы:
Мы не бросаем клиента через неделю, а стараемся выстраивать долгосрочное сотрудничество.
У нас не один специалист, а несколько проектных команд, не понимаю, откуда вы взяли такую информацию в своих расчетах.
Это высококонкурентный рынок с высокими требованиями к поставщику услуг. Большая часть клиентов — это рекомендации и сарафанное радио. Поэтому основа подхода — именно решить проблему клиента, если мы её не решим, он нас не порекомендует.
Вы изначально неверно истолковали чек-листы и продолжаете к ним делать отсылки. Чек-лист, это перечень признаков по которым можно оценить склад поверхностно и с определенной точностью выявить необходимость в профессиональном отдельном решении. Чем больше попаданий, тем больше вероятность, что нужно отдельное профессиональное решение. Окончательное решение, естественно, в каждом отдельном случае должно приниматься на основе полноценного профессионального внешнего или внутреннего аудита.
В любом случае, спасибо за обратную связь. Нам важно мнение штатных сотрудников на местах и мы его всегда стараемся учитывать.
Хорошее сравнение в комментариях....
У меня здесь есть УНИВЕРСАЛЬНЫЙ КОМБАЙН за 1 млн.рублей (ERP), которая может всё. Правда я НАВЕСНОГО ОБОРУДОВАНИЯ купил массу, ДВИЖОК расточил, ТУРБОНАДДУВ поставил - я комбайн тюнинговал 4 года и настраивал.
В штате этим занималось 4 айтишника (а как вы хотели, ведь это же ERP), потому что угодить надо было всем: закупки, финансы, бухгалтерия, продажи и где то там логистика.
Архитектор БД - неприкасаемый человек, только он владеет "как тут всё устроено". Миллион доработок за 4 года, изменение учётных сущностей, "задвигание" склада в зад и доработка по остаточному принципу.
В итоге имеем махину, с косилкой, бороной, фрезой, дополнительным баком, освещением и культиватором...НО - ей не разрешён выезд на дороги общего пользования. Комбайн отлично работает в поле, под управлением механика, комбайнёра и семи техников.
Но тут приходит молодой прогрессивный директор по продажам и говорит, нам бы в соседнем регионе поле (маркетплейсы) окучить. Посадить ячмень, а осенью сварить пиво. Но разворот этой махины требует доработки: разобрать, снять навесное, погрузить на трал, довезти, собрать, снять жильё для специалистов и пр.
Я продолжу.
Пока разворачиваем эту операцию - поле уже засеяли на десяти местных тракторах (пусть Беларусь).
Вот ERP он по факту такой.
Мне как нач.складу, директору по логистике в прошлом виделось в нескольких компаниях именно так. И компании, кстати, не мелкие, а стабильно входящие в пятёрку крупнейших в отрасли. Мне что бы изменить порядки обхода, добавить ЧЗ, разработать интеграцию с маркетплейсами, протестировать идеи, внедрить роботизацию - ты просто идёшь через АД объяснений о "сущностях" в ERP и функциональных разрывах где то.
Адовая хреновина ERP на интеграцию с простыми системами требовала миллионы рублей и месяцы разработок. Можно конечно сказать - программисты и разработчики плохие. Да, но мне то что делать как заказчику?
Дальше следующая ступень - Исполнительный директор. Т.е. теперь я выбираю и IT Директора и систему (конечно же советуясь с IT директором). Но кому работать в WMS, исходя из моего 15-ти летнего опыта Директором по логистике? Точно не IT директору. И все отсылы к универсальной системе говорят мне только о рисках и будущей неповоротливости этой махины. Простота интеграций? Нет. Я видел как и легко интегрирующиеся c системами ERP, так и ... "Стоимость интеграции составит 200 миллионов рублей и полтора года! У нас сильно модернизированный ERP! И это не шутка!!!
А видеонаблюдение кто то пробовал интегрировать с WMS в ERP 1C??? Получилось?
Мне как человеку опытному в логистике, как человеку отвечающему сейчас в целом за бизнес - интересней иметь несколько систем, которые ОЧЕНЬ гибкие и готовы к вызовам современного бизнеса в мире. Так же важно иметь внешнюю команду на обслуживании системы или систем, т.к. с точки зрения бизнеса - я перераспределяю риски. Хакнули одно - работает второе, отключили свет - работаем на листах с фонарём, лёг ERP - работаем в WMS, легла WMS - берём заказы из ERP.
В логистике зачастую всё решается на коленке, а потом заворачивается в доработку и доработка должна быть быстрая и чёткая. Она не должна затрагивать иные сущности, финансовые контуры и прочую несусветицу в ERP.
Я не АйТишник, я логист, я с низов понимаю что такое "шапка, которая сканируется как носки, а на самом деле это куртка" и что такое "два ведра с краской без партий на складе, но с партиями у финансистов, т.к. закупались по разному курсу".
И да, кто бы что ни говорил, развертывание и запуск WMS ГОРАЗДО быстрее реализации WMS в ERP - это я тоже проходил. ERP поддерживают свои Айтишники и они ОЧЕНЬ далеки от склада, а Директор по Логистике не хочет на год становиться Айтишником. Те кто массово запускают WMS, всё таки, имеют хороший опыт на складах - даже могут поделиться знаниями и примерами.
Любя информационная система , любой комплекс систем , архитектур зависит от людей и способности выстраивать диалоги и видеть цель - такого 5% остальное в компаниях это борьба подразделений, перетягиваний одеяло и прыгания перед забором что бы шеф увидел какого-то молодца который показывает работу… если в копании есть понимание, кто чем занимается можно строить как монолитные системы ERP и с минимум персонала либо сегментированное системы обвязанные между собой . За то и за это нужно будет платить , остальное просто как считать - это уже философия, рассуждения, взгляды с разных мировоззрений.
Я очень пониманию автора статьи, когда в компании есть экспертиза в виде сотрудников и когда она пропадает - это боль для компании и боль когда приглашают интегратора что бы разобраться - а не каждая компания, генеральный директор, собственник готов менять свои бизнес процесс которые работают (худо, бедно)…
Почти все в статье работает из коробки в SAP...
ERP vs WMS: причины не разрабатывать WMS на базе ERP (1C, Галактика, SAP) и мифы