Гость мимолетныйПриветствую.
...
Может кто без рекламы сказать, действительно ли толковая система?
Подойдет ли для предприятия с многопередельным производством, большим количеством номенклатур (может доходить до 1,5 тыс.) (легкая промышленность), нестандартными методами начисления з/п (всевозможные перерасчеты, массовые корректировки) и т.д.?

С рекламой: сколько стОит (усредненно, ессно)?

По порядку:
1.Действительно толковая. ИМХО одна из лучших. После знакомства с "лучшими западными" сказал бы "в мире".
2.Подойдет среди списка внедрений сложнее найти с меньшим числом номенклатуры - невольно возникает вопрос: может слишком простое производство и слишком большая часть функционала не понпдобится?
3.Подробней из массовых корр.З/п знаю только премию на "отдел,Бригаду, участок" ну и соответственно депремирование в остальном надо соблюдать хотя бы видимость КЗОТ - и соответственно документооборот ОК и ОТИЗ.
4.Наиболее правильным прикидочным методом будет: - Берем стоимость проэкта для любой импротной делим на 3 получаем верхнюю оценки для нужного функционала. Более точно сказать без калькуляции сказать нельзя.

Давайте конкретные вопросы попробую ответить.

Лирическое отступление: Для работы надо иметь богатое воображение.
Например вопрос - чем удобнее забивать гвозди?
1.Микроскоп
2.Молоток
3.Топор
Пример ответа - Смотря какие. ИМХО:
для новечка лучше всего микроскоп - сложнее попасть по пальцам
Для мазохиста - молоток
Для професионала - топор, им гвоздь забивается одним ударом без риска согнуть.
____________________
В каждой шутке есть доля шутки ....

Всегда старался обращать внимание на содержание, а не форму.
Главным в письме было предложение задавать вопросы – не хотелось говорить рекламными штампами.

Для желающих проверить п.1 предлагаю:
Напишите перечень преимуществ системы, которую хорошо знаете, задачи которые она решает единственная или лучше других. Я расскажу, есть ли это в IT-Предприятие. Может выйти неплохой сравнительный тест.
Две просьбы:
1.Называйте имя и версию системы, с которой сравниваем.
2.Избегать общих фраз. Пример: "У нас имеется возможность рассчитывать ПС по методу ABC". Много времени уйдет на достижение понимания терминов. Желательны примеры с цифрами.
...
Понимаю, что язык человека много говорит про уровень интеллекта и отношение к собеседнику. Приношу свои извинения тем, кто принял на свой счет, как говорится "И в мыслях не было".

p.s. «Интересующимся»- попробуйте поработать на микроклавиатуре вовремя езды...
________________________
Добрее надо быть. Добрее ...

Диалога не получилось…

Попробуем объять необъятное:

1. Система соответствует стандарту MRP II. Имеется финансовое планирование и планирование кадровое, следовательно - можно говорить о ERP.

2. Параметрически настраиваемая. Есть возможность централизованно или отдельно для каждой подсистемы менять настройки. Устойчивость к изменениям «после запуска» высокая – т.е. менять можно не все, но большинство изменений отрабатывает корректно «на автомате» не вызывая рассогласований в работе модулей.

3. Иерархия меню: Контур (подсистема)/Модуль (АРМ)/Папка (Пункт меню)/Функция. Принцип организации – по функциям отделов Пром.предприятия. Можно исключать любые пункты и создавать собственные через администрирование. Пользователь может создавать и управлять «Избранным»

4. Доступ прописывается для «ролей» (в системе –«групп пользователей»). Один пользователь может иметь несколько ролей – используя их параллельно или по очереди.

5. Уровень открытости высок. Администратор имеет практически те же возможности, что и разработчик: Таблицы, функции системы, отчеты и отборы, внутренние методы, экраны, гриды … все это (кроме функций) может быть использовано «как образец» для создания собственных и подмены стандартных. Причем часть этих возможностей доступны для пользователя (если администратор не запретил). Все описывается средствами системы, что исключает «конфликт изменений».

6. Функционал включает (ИМХО) три крупных контура:

a. Кадры + З/П. Основой контура являются Личные дела + приказы (и другие документы вроде больничных) по ОК, штатное расписание. З/п опирается на документы ОК, если ОК не автоматизируется – нужные документы вводятся в з/п.
Связь с остальными подсистемами:
з/п экспортирует свои документы в виде проводок, и импортирует проводки в себя (например: авансы, ссуды, матпомощь и т.д.).
Остальные модули используют справочники – табельные номера (материально ответственные, подотчет, подписи к чертежам …), тарифы (для работ в производстве), календари и т.д.

b. Производство: Спецификации, Модели (составы), нормы, техпроцессы, Извещения на изменения (со своими моделями отработки), Планы производства (до уровня MES) , графики работы оборудования. Подготовка производства позволяет получать документацию по ЕСКД, ЕСТД (отрасль надо уточнять, но основные формы - есть). Для «затравки» скажу – имеется возможность вести все варианты изделия в рамках одной модели (альтернативы) и прописывать условия выбора модификаций для состава (так называемое «ведение проекта»)

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

7. Самым большим достоинством системы считаю ИМХО «идеологию» или общий принцип построения (как любой общий принцип соблюдается он, увы, не везде). Краткий экскурс (грубо): Первым принципом построения КИС был MRP (ERP) – «Все источники эффективности находятся внутри системы». Со временем стали ясны ограничения данного подхода и появился CRM, провозгласивший: «Деньги нам платят клиенты – ориентируемся на рынок» т.е. главная эффективность – вовне + способы воздействия на «окружающую среду».
Принцип, примененный для построения системы я назвал бы: «Эволюционным» - «Эффективность системы напрямую зависит от ее возможностей приспособится к изменению внешних и внутренних факторов». Гибкость и устойчивость, контроль – основные требования. Данная система не требует предварительной реструктуризации (или хотя бы изменения документооборота) – она позволяет автоматизировать процессы «как есть» (без фанатизма - «петли» и «неопределенности» пройдется исключить), а затем, когда информация будет в системе начать менять схему в сторону «как надо». При этом, когда все документы в системе, у аналитика появляются средства анализа и контроля: можно четко определить «сколько» документов, «кто» будет вводить требуемый реквизит (а кто контролировать), «Откуда» будет браться для этого информация и степень ее достоверности. И только после начинать менять логику работы документов – имея возможность откатится назад. Такой алгоритм не требует коренной ломки, не грозит полной остановкой работы и может внедряться постепенно (эволюционно).
Так же вносятся изменения связанные с законодательством, структурой предприятия (слияния, покупки, создания СП и т.д.), или видом деятельности.

8. Бухгалтерия позволяет анализировать операции в разрезе следующих аналитик:

a. Счет/субсчет – 10 знаков. На счета, имеющие нижний уровень нельзя вводить проводки. Бывают: балансовые, забалансовые (корр. с балансовыми запрещена), аналитические (корр. с любыми используются в упр.учете)

b. Подразделение – структурная единица предприятия (сквозная для всех систем)

c. Контрагент/табельный номер – ссылка соответственно на справочник организаций или на собственного сотрудника. Возможны счета, где и организации и сотрудники – реализуем неликвиды, например.

d. Инвентарный номер – для учета ОС.

e. Пять произвольных пользовательских аналитик – можно прикреплять иерархические (вроде счет/субсчет) или любые другие.

f. При наличии контрагента появляется возможность добавить след. реквизиты: Договор, номер документа облиго (спецификация, счет-фактура, вексель), номер операционного документа, позиции операционного документа.
Описанные аналитики можно выстраивать в произвольном порядке: контрагент/Договор/счет.; Счет/субсчет/вид бизнеса (произв.аналитика); Табельный/счета (ссуда, подотчет)

9. Учет материалов заточен под производство, – какие атрибуты документа могут учитываться стандартно, и не перечислю (код ТМЦ, Складской номер, партия, контрагент, складоместо …) главное наличие двух полей (отдельно расход отдельно приход) где можно записать выражение по полям исходного документа. Имеется возможность ОДНОВРЕМЕННОГО учета в двух не связанных единицах измерения (сельское хозяйство и некоторые типы производства). Нет (надеюсь пока) учета в валюте отличной от базовой, нет возможности хранить вторую цену. Есть полная реализация FIFO с пересчетом всех позднее введенных документов и переформированием проводок (если надо).

p.s. нельзя объять необъятное – Предложение о сравнении систем остается в силе.
_______________
Леопольд выходи …

[quot Флеймер
Смотрел на систему на выставке. Давно. - Функционал понравился.
Потом общался с человеком который с ней работал. Он очень ругался. Мол с наружи все нормально, а внутри похабно. Тянет на клиента десятки мегабайт справочников. Грузит сеть. Сильно матерился на организацию работы удаленных точек.[/quot]

Судя по всему еще файл-сервер. Хотя на и на нем 21 машина работала на "общей шине" Eternet-10 и жаловался только P100 ;-))) . Может через модем подключались? Тогда надо через терминал.

Была еще проблема, когда при попытке отобразить номенклатор продукции, на 40000 записей, в виде дерева приходилось ждать минуты 2. Но для таких пользователей был вариант в виде линейного списка, он отрабатывал секунды. Теперь и "иерархию" поправили (тормозил, судя по всему не выбор, а добавление в стандартный Windows компонент - перешли на свой).

Для удаленных точек есть .NET-клиент (а терминалом пользоваться можно было уже давно). И в нем единственном видел возможность, когда клиент получает не весь запрос, а нужное число страниц (правда по умолчанию стоит 666 :-( ).

Словом странно… Откуда человек был? Может подсказать что?

asd_cioПо поводу успешных внедрений. Есть такое предприятие – Горловский мясокомбинат которое на их сайте числится как успешное внедрение .

Честно говоря, мало что понял - кто кого и на что менял. С «пищевиками» дела не имел, но некоторые общие вопросы все же можно выделить:
asd_cio
Средняя стоимость системы 100 тыс. $
...
Короче успели потратить только 50 тыс. $

То есть купили только лицензии, а внедрялись в кредит?
похоже именно так -
asd_cio
(раньше выбить 300 баксов была проблема)


asd_cio
о материальном учете и говорить просто страшно – исчезли остатки

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

2.Командой DELETE <имя таблицы> из Query Analyzer или "очистить таблицу" из меню администратора. При этом - надо "не забыть" отключить вторичные ключи (там две таблицы). Сделать это может только пользователь с высокими полномочиями.
Исправить это можно следующим образом -восстановить бэкап, зайти в настройку "Варианта учета" по материалам и выполнить любое изменение, сохранится, затем вернуть в первоначальное состояние, на вопрос "пересчитывать остатки" ответить "да" - система пересчитает остаток по "новому" варианту учета по документам движения.

3.Кстати этот же способ подойдет и для "пропажи" остатков (если сказать "не ведется"). Особенно если входящее сальдо вносилось не "приходами", а напрямую через UPDATE. На будущее - остатки лучше вносить "Актом инвентаризации", его проще и исправлять (остается история), и перепроводить, и программно он генерируется элементарно.
_______________________
Ненавижу кошек ...

LSV - Согласен с Вами, до последней запятой.
Именно это и подразумевал, когда предлагал системы сравнить.

Леопольд
Субд используется как хранилище флэт-файлов, ну оно и понятно - тупо конвертировали из DBF и все.

Было такое. Года четыре - пять, как прошло.
Леопольд
Application-сервера при этом нет.

Есть только он скорее "сверхтонкий" - отвечает только за интерфейс.
Что ИМХО несомненное достоинство. Ой! - сейчас бить будут.
Леопольд
Нормализацией таблиц не пахнет, как и правильными ключами. Что такое "план запроса" разработчики, IMHO и не слышали.

Более чем спорно. Практически любой отход от "третей нормальной формы" имеет серьезный "прецедент" (типа "черная икра" + шлеп="зеленый горошек").
Про "план запроса" слышал даже я. И вряд ли не слышали люди создавшие собственный "анализ времени выполнения запросов".

Леопольд
Отчеты как там строятся видели? Аля SELECT * FROM {штук 10 разных таблиц} тянется на клиента, а на клиенте уже все рассчитывается.

Там после "FROM" идет "join" по вторичному ключу (как правило - если это системный отчет, а не администратор запрос писал).
Леопольд
Демо версии почему нет? Да вот из-за этого и нет.

Увы. Есть впечатление, что каждые 1,5 года систему переписывают с ноля.
Даже HELP толком не успевает догнать. Все изменения можно узнать только из "потока корректировок".
т.е. рассказать систему сможет только тот, кто в ней живет постоянно.
При этом желательно знакомый с отраслью.
Да и внутри отрасли:
-очень многое находится на уровне настроек бизнес процессов и их взаимодействия - как составить демку из 200 документов? Кто в ней разберется? А иначе скажут - "ERP система, а этого и этого нет...".
- документы у всех разные - одни "лимитно-заборные карты" в лучшем случае по советским временам помнят, другие жить без них не могут. При этом - за день можно сформировать рабочий пример, который уже можно показывать/ставить,- вот никто демкой и не озаботился, хотя пора бы.
___________________
Самое страшное слово в ядерной физике - "Упс"

Судя по сайту:
" Проект комплексной автоматизации предприятия путем внедрения ERP-системы “IT-Предприятие™” был начат в августе 2004 года. В состав первой очереди включены модули технической подготовки производства, управления производством, комплексного бухгалтерского и налогового учета, оперативного учета материальных ценностей, управления ценами, управления сбытом, оперативного учета движения материальных ценностей, контрактно-договорной учета, управления кадрами, администрирования и управления доступом.
Поставка системы на предприятие выполнена на платформе MS SQL Server 2000. Проводится обучение персонала, подготовка информационной базы. "

Ребята, похоже, ввязались в "бесконечное внедрение".
Варианта два:
1. Или попался камень, который не объехать ни перепрыгнуть и сейчас ложками роют подкоп.
2. Или завод держится за руку и боится ее отпустить. А зачем? Опытные люди всегда под боком всегда присоветуют, изменения получаем бесплатно, а что две системы в параллель - так за два года привыкли - если отказаться от одной, то почем вторую сверять?
Хотя, если честно, одновременно управление производством и бухгалтерский, налоговый учет - кусок шире горла. Все равно придется делать "по частям" - а для такого внедрения год и 10 месяцев это не срок.

asd_cio
Вообще-то если говорить об общих вопросах с пищевиками – непрерывное многопредельное производство товаров имеющих ограниченный срок хранения (про вино, коньяк и водку попрошу не умничать ) + сбыт этой продукции.
Умничать не буду. Увы - некомпетентен, спецификой отрасли не владею. Единственное, что помню, в партии есть дата производства и дата до которой хранить, а в ОЗМ есть срок хранения. Сбыт же можно реализовать во всех разрезах – по секторам, группам контрагентам, менеджерам, регионам и чего душа пожелает. Имеется возможность, и указать, у кого хранится товар (при ответственном хранении). Эта часть вроде знакома, хотя на не претендую даже на «полноту».
Ничего - еще покричим, и появится тот, кто этот проект делал. Он все и расскажет.
asd_cio
Я привел Вам конкретный пример – опровергайте, либо убирайте с сайта информацию не соответствующею действительности. Ведь кто его знает сколько таких еще предприятий.

Вы меня спутали - я не Разработчик, а просто бизнес-консультант. И про другие системы могу рассказать тоже не мало, только там про недоработки будет побольше ...
_____________________
Жизнь - надо любить, животных - достаточно уметь готовить :) .