Посоветуйте программу Учета на предприятие

[Mr.Bean]

И опять же, озвучь хотя примерное количество документов и номенклатурных позиций по складу в вашей конторе. ...

Передо мной лежит складская ведомость на 1000 позиций (от видеостены до шурупа) полагаю это не предел, поскольку IT-железо постоянно эволюционирует, и за следующий год, количество позиций может дойти до 2000, а может и больше.
Документов? ну приблизительно 10 на поступление железа, 5 на перемещение и 10-15 на отгрузку......Получается около 25-30.

[ShineOn]

2000 по номенклатуре и 50-100 документов - это очень немного! Смело смотри деморолики по ссылке в личке. Думаю, вполне потянет за глаза. Только бухгалтерию желательно оставить на 1С, я так думаю (стыковка с 1С имеется).

[BiBo]

Смело смотри деморолики по ссылке в личке.

Прошу открыть ссылки общественности

[ShineOn]

Ага, потом ногами пинать начнёте, скажете, что это дурновкусица и вовсе не ERP в полном смысле этого слова.
Я то просто хотел человеку помочь его сегодняшние потребности закрыть, а мы тут уже о высоких материях говорим.

[BiBo]

Со вкусом у нас у всех порядок, иначе не встретились бы на этом форуме, да и форума бы небыло
Я тоже "пытающийся навести порядок в работе"

[ShineOn]

Тоже верно... Делюсь своими соображениями.

Я Валере с его скромными объёмами (10-15 рабочих мест, ~20 документов в день, ~2'000 номенклатурных складских единиц) и общими потребностями (складской учёт, документооборот) рекомендую познакомиться с системой производства "Интерпрокома" под одиозным названием СУПеР. Не знаю, как оно точно расшифровывается по первым буквам, что-то типа Система Управления Предприятием и Разная-другая-фигня . Раньше называлась СКАТ (система комплексной автоматизации торговли).

Платформа - Lotus Domino. Хорошо (идеально?) подходит для документооборота, но для специалистов по реляционным БД покажется странным использование этой платформы в качестве СУБД. Ограничения по организации БД есть, но для указанных объёмов - вполне покатит. Теоретически можно использовать связку Domino с DB2, чтобы получить все преимущества реляционных БД, но в СУПеР такой связки не реализовано.

Деморолики здесь.

Грубая прикидка по затратам на приобретение софта

Сервер IBM Lotus Domino. Для малых предприятий (Валерина контора туда нормально попадает) сервер Domino идёт бесплатно (по крайней мере, по прошлогодней системе лицензирования). Если с этого года бесплатный сервер для малых предприятий исключили, то порядка $3'500..4'000 на сервер.
Клиенты IBM Lotus Notes. Порядка $150 на рабочее место.
Лицензия СУПеР на 20 пользователей: $4'330

В итоге затраты на софт для Валериной конторы составят:
- вариант для SMB: $4'330 + 20 * $150 = $7'330. Пусть будет грубо $8'000
- вариант для Enterprise: $4'330 + $4'500 + 20 * $150 = $11'830. Пусть будет грубо $12'000

В любом случае, в названный бюджет проходит без проблем.

Внедрение как таковое отсутствует, система работоспособна "из коробки". При необходимости развития системы под локальные требования заказчика лучше пригласить спеца по Notes/Domino. Хотя не уверен, что самостоятельное развитие возможно, код могли заблокировать. Они и раньше открытый код давали только при покупке лицензий на максимальное количество пользователей (мне повезло, у меня была система ещё предыдущей версии с открытым кодом, простор для творчества был неограниченный).

[KostyaY]

Не соглашусь. Нормально эксплуатируем с распределенкой, все живы здоровы.

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

А вообще, в 1С меня больше всего прикололо вот что - объем базы у нас порядка 1 гига (это только бухгателтерия, как уже говорил ранее), и с 5 (пяти!) рабочих мест работать было невозможно, так как постоянно возникали встречные блокировки, а закрытие периода занимало порядка 12-14 часов, причем в это время вообще работать никто не мог. Мы, естестственно, предъявили претензии внедренцам, на что они развели руками, порекомендовав для таких объемов прикупить SQL версию продукта. Хрен с ним, прикупили. После чего попытка закрытия периода стала вызывать ошибку нехватки оперативной памяти на машине с 3 (тремя!) гигами оперативки. Я некоторое время имел внедренцев во все дыры, грозился подать в суд, дабы они обеспечили работу продукта на машине с заявленными минимальными аппаратными требованиями (256 Мб), но их действительно отчаянные попытки что-то сделать успехом не увенчались. Плюнув, поставил машину с 4 Gb, специально для этих нужд, после чего период стал закрываться на ней за 3.5-4 часа. В это время, кстати, никто не может работать по-прежнему.
Я не знаю, должно быть так, или нет...
Для сравнения, объем БД Навижн был у нас порядка 160 Gb, причем, она была развернута на относительно маломощном сервере, на котором работало куда поболее народу, но, почему-то, всё бежало быстро. Хотя и данных, и функционала там больше на порядки.

1000 позиций (от видеостены до шурупа) полагаю это не предел, поскольку IT-железо постоянно эволюционирует, и за следующий год, количество позиций может дойти до 2000, а может и больше.
Документов? ......Получается около 25-30.

C таким кол-вом легко справится что угодно!
Не думал на предмет заказа у какого-либо студента простейшей базы на Access? Возможно, это будет самый дешевый вариант. А то, что нужно для бухгалтерии, выгружать в 1С. Или же сразу пользовать 1С в какой-нить простейшей комплексной конфигурации?

[BiBo]

Хм. Интересное предложение, но на сколько я понял это вполне жизнеспособное решение из коробки? Не встретил в описании "Планирования закупок/прогнозирования запасов", как это реализовано?
В предложенном мной варианте это выглядит следующим образом: "инструмент средневзвешенного прогноза"
Чего я не додумался, так это прикинуть по затратам, итак:
AVA Lite: Рабочие места, включенные в стоимость - 10, Количество рабочих мест - Не более 30, Цена - 250 000 рублей (примерно 8100$)
Всё это крутится на сервере Oracle Database, соответственно + 100$ за каждое рабочее место
Итого для AVA Lite: 8100+10*100 = 9100$ на старте.

Как то так.

[ShineOn]

на сколько я понял это вполне жизнеспособное решение из коробки?

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

Не встретил в описании "Планирования закупок/прогнозирования запасов", как это реализовано?

В номенклатурной карточке продукта есть поле "Минимальный запас на складе". Раз в день (можно чаще) запускается агент, который сравнивает заданные минимальные значения со складскими остатками + резервами по планируемым отгрузкам. На основании этого сравнения ответственному за поставки приходит письмо со списком заканчивающихся позиций. В старой версии заказы на поставку на основании этого списка надо было делать руками, но в самом заказе можно легко выбрать продукты, которые относятся к выбранному поставщику. Возможно, в новой версии создание черновых заказов автоматизировали, врать не буду. Но, в принципе, даже в старой версии не вызывало вопросов.

[Страусь]

Платформа - Lotus Domino. Хорошо (идеально?) подходит для документооборота, но для специалистов по реляционным БД покажется странным использование этой платформы в качестве СУБД. Ограничения по организации БД есть, но для указанных объёмов - вполне покатит. Теоретически можно использовать связку Domino с DB2, чтобы получить все преимущества реляционных БД, но в СУПеР такой связки не реализовано.

Тебя не смущает странность выбора. Разработчик учетной программы решает в качестве базы данных использовать не DB2, Лотус ноутс, который как бы для другого предназначен. Мне это выглядит странно. Я бы подумал, что у них был спец по лотусу, он начал че-то делать. Бросать это не решились.

В итоге затраты на софт для Валериной конторы составят:
- вариант для SMB: $4'330 + 20 * $150 = $7'330. Пусть будет грубо $8'000

Для заявленных объемов цена поднебесная.

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

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

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

Ты бы тогда так и написал. А то написал, как будто распределенка кривая и не работает. У нас клиенты работают с филиальной сети. По России. И на 7.7 и на 8 платформах. И ничего, все штатно, все нормально.
Но для автоматической репликации наверно надо другие средства применять.

[ShineOn]

Тебя не смущает странность выбора.

Я же сразу оговорился, что спецам по SQL выбор платформы покажется весьма странным!

Я бы подумал, что у них был спец по лотусу, он начал че-то делать. Бросать это не решились.

Там была длинная история. Изначальная система делалась "Интерпрокомом" (который один из двух крупных разработчиков систем на Notes/Domino) по заказу конторы, в которой я когда-то трудился. Ещё во времена Notes 2.x. Почему не выбрали другую платформу - не знаю, возможно, в те времена (1995-1996) не было нормальных SQL-серверов и средств разработки под Windows и/или OS/2 (изначально у нас сервак крутился именно на OS/2, потому как Windows NT Server 3.51 был ещё весьма сыроват).

А потом уже да, им жалко было бросать работоспособную наработку. Расширяли функционал, насколько позволяла фантазия и возможности платформы (c выходом принципиально обновлённой платформы Notes 4.x возможности значительно расширились). Жаль, что не хватило смелости сразу перейти на связку с каким-нибудь реляционной СУБД, например с той же DB2 (хотя грамотная интеграция с DB2 появилась только в Domino 7.0 лет этак через десять). В результате на довольно больших базах производительность была бы заметно выше (в той версии, что я застал на момент увольнения, при 8 миллионах записей тормоза были не просто заметны, а типа как у Кости - любая операция по складу могла занимать несколько минут). Но на тех объёмах, что озвучены Валерой - вообще проблем быть не должно.

Для заявленных объемов цена поднебесная.

Это уже решать заказчику. В озвученный бюджет укладывается, при этом не требует дальнейших вложений в сопровождение (при условии принятия функционала по умолчанию). При этом кроме автоматизации склада и торговли заказчик получает очень хороший документооборот (для него Notes/Domino идеально подходит).

Я бы на Аксесс сейчас не рискнул бы.

Согласен. Будешь тупо завязан на того программера, который будет изобретать эти костыли.

[KostyaY]

в те времена (1995-1996) не было нормальных SQL-серверов и средств разработки под Windows

О-о!.. В те годы вообще не было понятно, какие настольные/серверные ос имеют будущее, какие - нет. Хотя и SQL сервера были, и средства разработки (хотя и не такие красивые, ка сейчас). Лотус же в ту пору занимал, насколько я помню, довольно твердые позиции в области систем документооборота, а вопросы работы с базами данных, вероятно, заказчика не особо интересовали - скорее всего, исходно не предполагались большие объёмы.

Да, с Access'ом связываться, конечно, не стоит, именно по причинам, упомянутым Игорем и Алексеем. Тем более, что бюджет позволяет выбрать что-либо готовое.
Пример был приведен, скорее, в том смысле, что даже десктопная БД справится с поставленной задачей.

В любом случае, решение должно быть масштабируемым - т.е., если вдруг изменится архитектура предприятия (например, появится 10 складов, 50 точек продажи ) и/или объемы документов возрастут порядка на 2, ну и т.п., должна быть возможность либо апгрейда системы малой кровью, либо относительно несложного извлечения наработанных данных для перехода на другую систему. Об этом тоже задумываются нечасто, в результате совершенно невовремя есть риск наступить на грабли.

Добавил через 11 минут
Да, к вопросу о стоимости...
Сейчас поднял, сколько было потрачено за 1.5 года на 1с (доработки, лицензии, сопровождение и т.п.) - около 550-600 тыр. И это только бухгалтерия. Рабочих мест около 15. Основное - это "небольшие" доработки, преимущественно по требованиям бухгалтерии, кое что по обмену, но это немного. Что забавно - бухгалтерский баланс в 1С не был сведен за эти 1.5 года ни разу, делали вручную... Обещают свести этот год, но у меня уверенности в этом, почему-то, нет.

[ShineOn]

Хотя и SQL сервера были

Были, я не спорю. Но большей частью под UNIX, который в те времена поставлялся только на приличной (по стоимости) технике. FreeBSD широкого распространения в России ещё нашёл, про Linux тогда ещё вообще никто не слышал, Solaris только-только портировали на PC. Дремучие времена были...

[Страусь]

Да, к вопросу о стоимости...
Сейчас поднял, сколько было потрачено за 1.5 года на 1с (доработки, лицензии, сопровождение и т.п.) - около 550-600 тыр. И это только бухгалтерия. Рабочих мест около 15. Основное - это "небольшие" доработки, преимущественно по требованиям бухгалтерии, кое что по обмену, но это немного. Что забавно - бухгалтерский баланс в 1С не был сведен за эти 1.5 года ни разу, делали вручную...

Неплохо, совсем неплохо. За небольшие доработки заплатить 450 тыщ ... Живут же люди!

[KostyaY]

Живут же люди!

Вот я и говорю, как хорошо устроились разработчики, да и производители этого продукта!

Были, я не спорю. Но большей частью под UNIX, который в те времена поставлялся только на приличной (по стоимости) технике. FreeBSD широкого распространения в России ещё нашёл, про Linux тогда ещё вообще никто не слышал, Solaris только-только портировали на PC. Дремучие времена были...

Не-е...
В 1996 WinNT 3.51 пребывала уже в боевом состоянии и стояла у нас на боевом дежурстве. Именно в том году мы открыли для себя Цитрикс и практически полностью перешли на бездисковые терминалы, загружаемые по сети. И уже вполне годилась на относительно бюджетном железе как серверное решение для небольших предприятий и даже более.
Кстати, MSSQL 6 тоже был в эту же пору! Хоть под Альфу, хоть под i386.