Сеть магазинов на Меркурий-ERP : Системы автоматизации торговли

█ 30.03.2015 08:31

Цитата:

OlegON ➤ Это напрасно. Мы тут никто Супермаг не продаем и уж покритиковать его я очень даже люблю.

Олег, а как по твоему мнению, Супермаг стал таким распространенным?

█ 30.03.2015 09:26

Цитата:

alwaysright ➤ Олег, а как по твоему мнению, Супермаг стал таким распространенным?

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

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

█ 30.03.2015 10:06

У асторовцев ценник вообще запредельный для провинции ИМХО. Я считаю, есть шанс с бюджетным решением для сегмента Б и Ц. от 10 до 100 магазинов. Таких сетей море. Да и новые открываются до сих пор. Плюс, мы не концентрируемся только на сетях. У нас и оптовая есть торговля. И производство мощное (на много цехов) с планированием, преферансом и куртизанками. К лету допишем управление ресурсами и задачами, сможем планировать загрузку производственных мощностей. На фронте, через пару недель, будет функционал кафе/столовой готов. Вот и получается мультикомбайн на все случаи жизни. К тому же кризис, а мы можем и рассрочку предложить и ценник скромный у нас.

█ 30.03.2015 10:08

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

█ 30.03.2015 10:18

Я уже много лет на Линуксе, поэтому со стойким убеждением, что лучше Unix-way еще ничего не изобрели, а чем более многофункциональна программа, тем менее она надежна и хуже работает. Мой совет, если он интересен, двигаться в сторону большего количества модулей, работающих отдельно, но поддерживающих друг друга, чем в сторону одной и тяжелой софтины. Пользователь испытывает стресс, если его сразу посадить за пульт управления полетами. Опять же, разделять разработку и согласовывать труднее большой модуль, чем кучу маленьких с единым стандартом обмена. Я на слово "мультикомбайн" так среагировал. Все остальные пункты, извините, зависят от того, кто у вас будет непосредственно разговаривать с потенциальным клиентом. Это тоже надо уметь. Продать можно что угодно и кому угодно, даже сейчас. Вопрос только умения окучивать клиента и убедительно предоставлять ответы на все его хотелки.

█ 30.03.2015 10:51

Ну разбить по модулям, совсем по разным экзешникам не так трудно. Но работать им придется в одной базе. Вот как пример модули "Управление запасами" и "Производство".
Когда мы рассчитываем сколько полуфабриката произвести на конкретном участке, мы смотрим, сколько заказано и отнимаем текущий остаток. Все просто. Но в реальности, надо оставить на складе страховой резерв "буфер", на случай проявления Мерфи, чтобы не допустить простоя узкого места производственной цепочки. Так вот, страховыми резервами управляет модуль "Управления запасами". Он их рассчитывает, хранит, отображает наглядно... Поэтому они в одной базе. Если мы их разнесем по разным БД и заставим синхронизироваться - дублирование данных, лишние синхронизации и т.д.

█ 30.03.2015 12:10

Нет-нет, я не предлагал БД делить, я про то, что работает на стороне пользователя. Хранилку, как раз, лучше одну держать, чтобы не дублировать данные.

█ 30.03.2015 23:02

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

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

█ 31.03.2015 11:40

Цитата:

FinSoft ➤ В винде изначально предполагается модульная архитектура - dll.
Что нужно использовать внутри модуля, там и остается, что можно использовать извне (других модулей), экспортируется. Часть dll можно подгружать по мере необходимости (всякие отчеты, обработки). А если подгружать неудобно, а функционал для многих клиентов не нужен, можно просто изготовить модуль-заглушку (т.е. список экспортируемых функций такой-же, но в реальности только пустышки).

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

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

█ 31.03.2015 12:53

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