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

Имеется набор складов под одной крышей общей площадью порядка 25 тыс кв. метров с 300-ми тысячами коробов продукции с разнообразными методиками адресного и неадресного хранения.
Адресный учет работает три года. Обычный - десять. На посекционном учете съели почти всех собак. Устраивает абсолютно все кроме низкой стабильности работы системы. Очень большое количество кода написанного разными людьми разной квалификации. Очень большое количество различных доработок, которые уже не нужны, но раздувают код. Наслоение версий посекционного учета (т.к. чаша у Данилы получилась не сразу). Как итог - невозможность глубокой оптимизации кода в рабочем порядке. В последний раз, когда пытались провести глубокую оптимизацию кода - очень долго разгребали проблемы.
Программа тормозит, блокировки, зависания, глюки НО ПОКА ВПОЛНЕ В РАМКАХ РАЗУМНОГО. На перспективу же 5-7 лет путь тупиковый. Через год-два будут реальные проблемы.

Стал вопрос - как выбрать 1С интегратора для автоматизации складского хозяйства. Обычных 1С интеграторов я оставляю на закуску, т.к. они напишут что угодно и даже покажут какой-то складик, где у них все хорошо работает и единственный кладовщик говорит "Яя зер гут".
А нам нужно комплексное решение которое будет работать заведомо стабильно и на перспективу 5-7 лет дарить радость и положительные эмоции.

Каким путем пошел я. Выбрал статьи о профильных форумах и семинарах. Те фирмы, которые повторялись это LogX, Акселот, Солво. Не спорю, что может быть есть еще какие-то очень известные по этому профилю. Только приветствую информацию о них.

Из этих фирм выбор остановил на Акселоте только потому, что у него все реализовано на 1С с почти полностью открытым кодом. У нас имеется штат специалистов 1С и будет расширяться для других задач, которые на перспективу после внедрения могут вести сопровождение этого продукта.

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

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

Хотел бы более подробно остановиться на техподдержке.
1. Как реализовано у нас. Техподдержка логистического блока осуществляется четырмя штатными программистами средней квалификации. Склад работает круглосуточно и между программистами организовано круглосуточное дежурство. При необходимости программисты иногда (редко - обычно все в рамках настроек и консультаций) ночью через модификацию кода и непосредственную правку таблиц решают проблемы чтобы "хоть как-то" прошло, а утром ведем разбор полетов и переработку изменений. Другими словами - все вопросы решаются он-лайн.
2. Даже если предположить, что новая автоматизированная складская система будет почти идеальной - склад всеравно будет работать круглосуточно. По моему опыту общения с техподдержцами не входящих в мой штат - никакого онлайна даже за огромные деньги мы не получим. Никто в три часа ночи не будет выслушивать кладовщика, у которого при сканировании короба выдается какая-то необычная ошибка. Поэтому, имхо, придется оставить штатных программистов, которые будут в первой линии техподдержки. А дальше они ведут эскалацию проблемы внешнему техподдержцу. Но! Почти все проблемы не терпят "подождать до утра". Плюс часто идет работа в выходные.
3. Получается, что наличия штатных программистов не избежать, а для того, чтобы был полный онлайн - они должны иметь доступ на практически любые корретировки программы.
4. Открытый код я так понимаю из WMS-решений только в 1С.
5. Вот так я и прихожу к тому, что 1С не избежать.

Ну и есть специфика. Мы находимся в небольшом городе в ростовской области. Никакой серьезный специалист сюда (например по тому же SAPу) не поедет. А если поедет, то их нужна пара (больничный, отпуск), а лучше тройку, т.к. два человека скуксястся в режиме 24/7. Думаю представляете сколько это стоит с проживанием. А так есть уже отдел, который съел собаку на посекционном учете с заработными платами порядка 20 тыс рублей, который 1С не владеет, но за годик овладеет на среднем уровне без проблем. Помимо этого есть пара штатных профессиональных разработчиков 1С, которые хоть и находятся в другом городе - вполне могут быть подключены к проекту как ключевые разработчики после ухода интегратора.

Программист 1с,

А что за система если не секрет?
У меня просто возникла небольшая заминка когда я пытался определиться что лучше - 1С Логистика от Акселота или просто 1С Торговля (в ней тоже есть механизмы адресного хранения).

Первоначально интегратор, с которым я общался предложил мне сделать все на Торговле, мотивируя тем, что ее проще сопровождать, да и решение дешевле получится. Хотя и не сильно отговаривал от 1С Логистика.
Я сам курил информацию по поводу полноты функционала адресного хранения, который нужен нам. Знаете - вроде как все есть, но по многим вопросам есть сомнение - будет ли все работать так как нам надо.

Другими словами - вопрос - чем реально плоха 1С Торговля? Чем она не WMS?

Программист 1с,

Кстати про логистикс у Вас не одного такое мнение оказывается

http://www.lobanov-logist.ru/new_forum/new_forum8/topic135/

maximaz,

Что касается ТЗ у меня мысль такая
0. Объявляем, что будет тендер на написание ТЗ, с последующей его реализацией (если сойдемся в цене после написания ТЗ).
1. Объявляем тендер чисто на написание ТЗ
2. В информации, которую присылают для тендера требуем подробную информацию о истории аналогичных или бОльших внедрений и подробно шерстим их.
4. Проводим тендер. Выбираем компанию, которая пишет ТЗ.
5. Написали ТЗ.
6. Компания дает нам КП на реализацию работ по написанному ТЗ. Торгуемся, либо вообще отдаем ТЗ в другую компанию (неоптимально, но мало ли что).
7. Реализация работ по ТЗ
8. Занавес.

В этом случае после написания ТЗ мы уже четко знаем сколько денег надо и в какой срок уложимся. До написания ТЗ - это призрачные оценки.

363, Программист 1с,

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

Плюс к межфирменности и объединению документов должны работать все сопутствующие механизмы когда надо что-то удалить, переделать, переучесть, и т.п.


Что касается блокировок. Реальная проблема. Но я думаю должно при переходе на другую платформу полегчать. Хотя бы потому, что сейчас логистический блок находится в одной комплексной базе со всем остальным функционалом, после вынесения на отдельный сервер - должно полегчать. Помимо этого, насколько я понимаю, 1С обладает неким набором механизмов для поиска узких мест и есть даже специализированные конторы типа Гладченко, которые занимаются оптимизацией. На нашей же платформе никаких Гладченко нет. Никто нам не поможет кроме нас самих. А мы далеко не суперпрофи. Что такое счетчики и трассировка мы знаем и умеем. А вот например с планами выполнения запросов и например филл-факторами подбуксовываем.


Ну и глобальный вопрос. А если не 1С и мы не в московской области. Склад работает в режиме 365/24/7. Вопросы отложить до утра нельзя. Стоит не 1С. Код закрыт или написан на каком-то фруфрляндском языке. Что делать? Неужели все не1Совские системы стоят только в Московской области где можно найти в штат спеца по какому фруфрляндскому языку? Что делать остальным? Вообще нифига не понимаю. Как работают люди на WMS-системах, внутренний код которых закрыт или открыт, но язык фруфрляндский?

Artem Kashin,

Сейчас почитаю поподробнее про эту тему!!

maximaz,

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

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

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

Artem Kashin,

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

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

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

В Москве оказывается будет проходить через 3 недели серьезная выставка по логистике
http://www.cemat-russia.ru/ru-RU
Там Акселота не вижу, но вижу огромное количество его конкуретов (из тех, названия которых знаю)
Бухта, Колумбус, Первый Бит, Солво,...
Будет замечательная возможность плотно пообщаться сразу со всеми интеграторами. Главное будет не забыть лапшефильтр.

363Kaktus_maximaz,

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

Ни в коем случае!
Как минимум функциональные требования для тендера и ТЗ должны именно ВЫ и формулировать СОВМЕСТНО с вашими внутренними заказчиками.

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

Я просто не могу не поделиться этой замечательной ссылкой.

http://infostart.ru/public/169500/

Она в том числе и про WMS и обнаружена была в поиске информации по WMS.

Злой Бобр,
Sheraton,

Да, на самом деле я очень хорошо разбираюсь в той системе, которая нами реализована. Я сейчас управленец, но ядро посекционного учета разрабатывались (программировались) непосредственно мной. Значительная часть интеграции этого ядра в существующую систему также проводилась мной. После этого другие программисты проводили весомые доработки и корректировки, но ядро сильно не модифицировали. Нам пришлось писать ядро дважды практически с нуля, так как в первый раз мы выгребли море логических ошибок, о которых не подозревали, но которые ломали всю работу склада.
В этом-то и есть основной плюс - мы четко знаем чего хотим. Но понимаем, что в предлагаемых решениях может быть заложена другая логика. Мы готовы идти на компромисс.
По поводу написания ТЗ. Его написать хорошо могу только я. Но тут у меня небольшой ступор.
1. Если я напишу ТЗ, то это будет описание того, что должна уметь система. Если я опишу слишком подробно, то получится клон нашей системы на новой платформе с возможными логическими проблемами. Если я опишу не слишком подробно, то могу получить функционал, который называется как надо, а работает хуже чем у нас.
2. Если я опишу наш бизнес-процесс. Опять же та же фигня - если слишком подробно, то клон, если не сильно подробно, то получаю риски.

Поэтому на мой взгляд:
1. Мы должны описать наш бизнес процесс очень детализировано чтобы иметь в руках, а не в голове полный функционал.
2. С этим описанием мы садимся с интегратором на месячишко-другой и он по каждому блоку делает нам предложения и подробные демонстрации как реализован каждый блок функционала у них в системе. Результат по каждому блоку - согласились ли мы, решили модифицировать систему или нашли компромисс - фиксируем в ТЗ. И фиксируем в таком виде, чтобы получившееся ТЗ можно было бы применить вместо ТЗ на другую платформу хотя бы процентов на 80.




363,

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

Elias33,
Гавриил Пришвин,
Artem Kashin,

Спасибо за предложения рассмотреть WMS Ваши решения - я обязательно проработаю информацию по ним.

Скажу честно, что пока у меня в приоритете Акселот. Почему - да потому, что это 1С, которую мои сотрудники могут выучить и быть перспективными, а также я буду иметь определенную безопасность при уходе сотрудника. Если же это будет экзотический язык (да наверное любой другой кроме 1С), то ребята не будут перспективными (нужно ехать в большие города чтобы найти аналогичную работу), а также я не буду застрахован - где я найду спеца со знанием Prologа (а именно на нем и на C++ написана одна из реальных WMS. Да и не очень мне нравился в свое время Prolog. Трояк у меня по нему).

Но. Даже не "Но", а "НО!". Если я увижу, что функционал Акселота нужно будет значительно дорабатывать под нас - это будет очень большой повод задуматься. Я не хочу, чтобы этот проект стал подопытным кроликом со всеми вытекающими. Я хочу чтобы "из коробки" было практически все.
В этом случае я готов буду рассматривать системы не на 1С-платформах и буду как-то подстраховываться под экзотические языки программирования (опыт в этом очень большой).
Мне нужно чтобы проект был успешно реализован. И если у меня появятся сомнения в том, что на 1С это возможно - значит будет не 1С. Лоббировать 1С я не буду, т.к. сидеть в луже с плакатом "Зато мы работаем на 1С" мне не хотелось бы.

SpellBuilder,

Знаете. Я ведь и правда нигде не ковырял подробно межфирменность кроме нашего решения. Возможно у нас она реализована не оптимально. Постараюсь посмотреть что предлагают другие платформы. Хотя бы та же 1С.
И спасибо за наводку по Солво. Рассматриваю его как одного из основных игроков если ставка будет не на 1С.

Гавриил Пришвин,

"Когда вы просчитаете затраты на содержание своей команды и сравните их с затратами на сопровождение, то увидите, что выгоднее."

Знаете, я последую Вашему совету. Сделаю расчет и сравнение этих затрат после выбора интегратора. Даже ума не приложу что могу там увидеть, но очень интересно что получится. Даже если я засуну результаты под сукно исходя из каких-нибудь соображений, но все-таки хотелось бы знать правду. (Но меня пугает только одно - "Че правда мой кладовщик позвонит по телефону 8 495 3222232 и его проблему не отложат до утра, а сразу решат специалисты компании N".) НЕВЕРЮ. Если же кладовщик не может напрямую связаться с интегратором, а нужен промежуточный специалист, то в режиме 24\7 их нужно чтобы ходили по сменам 4 человека, а это вполне похоже на моих имеющихся программистов, которые не только могут транслировать проблемы, но еще и сами их решать.