решения для малого бизнеса

[АКн]

Уважаемые специалисты,

я представляю компанию МАЛОГО бизнеса.
Компания занимается заказной мехобработкой - изготовлением зап частей для различных промышленных машин.
Чаще всего изделия простые  не повторяющиеся - вал, шестерня, другое

Я занимаюсь продажами наших услуг, работой с клиентами.

Чертежи на детали ведем в бумажном виде ! В электронном виде чертежи появляются только через сканирование !

Вопрос: из вашего опыта подскажите, что можно выбрать из средств автоматизации для осуществления:
1. структурированного хранения чертежей и других документов по клиентам и заказам
2. документы для хранения (в разрезе заказа): чертежи, коммерческое предложение, простейший рассчет нормирования и структуры работ, материалы, оснастка, другие документы  (все документы МС офис)
3. поиск документов в архиве по различным параметрам
4. отслеживание статуса заказа - конструкторская подготовка, нормирование, коммерческое предложение, производство, выполнение
5. интеграция с 1С для подготовки бухгалтерских документов (счет на изделие, накладная и тп).

Предположительно в системе будут работать 3-5,6 человек
(менеджеры проектов (продажи), конструктор, технолог)

Был в Асконе насчитали  цены : Лоцман сервер + 3 клиента + обучение + внедрение = 200 тыс и более.

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

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

Спасибо.

[sulyco]

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

[АКн]

Ваша мысль понятна.

Мне все-таки конечно хотелось бы посмотреть готовое решение с минимальной разработкой.
Будем искать дальше 

[Горбушин Даниил]

5. интеграция с 1С для подготовки бухгалтерских документов (счет на изделие, накладная и тп).

Однозначно 1С-PDM, т.к. и задачи архива закроете и заказы удобнее вести будет - все в одном месте (1С).

Если уж совсем просто и дешево - спросите в АСКОН Компас-Менеджер. Если они его еще продают. Решение простое (состав изделия, архив и т.д.), а интеграцию с 1С своими силами думаю сделаете...

[YorikER]

Господа, может хватит заниматься откровенной рекламой пакета 1С-PDM на форуме конкурента? Весьма некорректное поведение... Я думаю, что Администратору пора обратить на это внимание... А руководителям АСКОНа серьезный звонок - пора двигать ЛОЦМАН в направление ERP и компактных конкретных решений для малых предприятий...

[Горбушин Даниил]

А руководителям АСКОНа серьезный звонок - пора двигать ЛОЦМАН в направление ERP и компактных конкретных решений для малых предприятий...

АСКОН обещал свою ERP еще год назад показать...

Разработка ERP - это вам не плагины под ЛОЦМАН писать - это серьезная работа. Это:
- Склад;
- Бухгалтерия;
- Учет движений материалов/ДСЕ с одновременным формированием бухг.проводок.
- Производственный учет с одновременным формированием бухг.проводок.
- Распределение затрат, учет себестоимости.
Много-Много всего надо разрабатывать.  :um:А в первую очередь надо понимать как разрабатывать...

Объектный ЛОЦМАН - это для PLM хорошо, но для планирования, логистики и учета - умрет после того как люди занесут информацию за неделю работы...

[YorikER]

Объектный ЛОЦМАН - это для PLM хорошо, но для планирования, логистики и учета - умрет после того как люди занесут информацию за неделю работы...

Вот здесь я не согласен... У нас в базе данных уже под 400 000 объектов и ничего... Работает уже третий год...

[Горбушин Даниил]

Объектный ЛОЦМАН - это для PLM хорошо, но для планирования, логистики и учета - умрет после того как люди занесут информацию за неделю работы...

Вот здесь я не согласен... У нас в базе данных уже под 400 000 объектов и ничего... Работает уже третий год...

Ваши 400 тыс. объектов в БД статичны.
А теперь представь, что вам нужно посчитать запас на складе по конкретному материалу. Надо все движения материалов просуммировать (+/-). В объектной БД вы будете выбирать объекты+атрибуты+связи, потом с выборкой делать арифметические операции. Сколько вы в ЛОЦМАН будете подобную выборку делать, если: материал был списан в производство на несколько заказов + были движения между складами?
А если отчет по складу МТС сформировать, где номенклатура порядка нескольких сотен позиций, а по цеху и того тысячи. Сколько времени выборка формироваться будет? А если подобные выборки выполняет одновременно 10 - 50 пользователей, не повиснет ли вся система на объектной модели?

[YorikER]

Опыт показывает, что не виснет... Конечно указанные задачи у нас не проработаны, но у нас единичное производство, две базы данных: одна электронный архив сканированной конструкторской документации (более 200 тыс. объектов) и БД конструкторской подготовки и части ТПП (более 400 тыс. объектов). Количество пользователей по заводу более 300... Конструкторских мест около 100... ТПП - 20... Остальные используют систему как справочную, для поиска нужной информации... Количество сквозных запросов поиска объектов в день - десятки... Пока проблем нет, затраты времени - секунды...

[Горбушин Даниил]

Вы не поняли...
ERP на объектной структуре - это объект с набором атрибутов на каждый чих... Проводка - объект, Закупка - объект, Движение материала - несколько объектов (для разных движений разные наборы атрибутов) и т.д....
Далее примитивный вопрос производительности, к примеру:
1. Производственный заказ. Спецификация заказа 20 компонентов (у нас есть и 1500 компонентов на сборку). Техкарты с 3мя операциями
2. Подтверждаем выпуск продукции: 1 движение по выпуску + бухг.проводка деб.21 кр.20
3. На заказ списываем работы: 1 бухг. проводка на одну операцию на одно рабочее место + сокращение резервирования мощностей.
4. Списание компонентов: 20 бухг. проводок + 20 движений материалов + по каждому компоненту надо проверить доступность на складе.

Итого, по результатам подтверждения заказа: Объектов = 48, Атрибутов > 200. И это после каждой операции.
А теперь посчитайте сколько будет через неделю объектов и атрибутов в системе при выпуске цеха в 1500 наименований и каждый день в течении недели. Взять даже коэффициент 0,4 т.к. некоторые детали делают сразу на месяц или неделю. Получаем:
Новые объекты = 1500 * 0,4 * 48 * 5 (раб.дней) = 144 000 объектов
Умножаем в среднем на 4,5 и получаем атрибутов: 684 000 атрибутов.
Добавляем перемещения материалов между цехами + еще 4 цеха и примерно через неделю будет:
Объектов около 1 000 000 (один миллион)
Атрибутов около 4 500 000 (четыре с половиной миллиона)

И как вы "на лету" собираетесь с таким кол-вом данным в объектной системе работать???

З.Ы.: Не учтены закупки, отгрузки (продажи), другие хоз.операции, так что смело можно умножить на 20, а то и на все 100 и потом на 51 неделю в году и получим 120 000 000 - 5 100 000 000 объектов за год

[Администратор]

Коллеги, прошу вернуться к теме: решениям для МАЛОГО бизнеса, а конкретно — для описанной топикстартером ситуации.

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

[YorikER]

Уважаемый Администратор, прошу прощения, но спор как раз о решениях для малого бизнеса... Даниил описывает ориентировочное количество задач и порожденных объектов именно в малом бизнесе... И прежде чем задавать вопрос, озвученный в начале топика, необходимо реально оценивать данные объемы... Именно к этому идет весь разговор... И на мой взгляд он весьма правомерен в данном разделе... Он поможет пользователям реально оценивать различные системы при их выборе...
1. У меня нет опыта реализации указанных задач, комментировать правильность расчетов не смогу... Думаю, что многое можно решить за счет грамотно проработанной структуры данных и разделения информации по разным БД... Что может сказать АСКОН по данному поводу? Было бы интересно услышать ответ от авторов системы ЛОЦМАН...
2. Даниил, я так и не понял, что Вы хотите сказать? Какой тип БД более подходит под описываемую Вами задачу? Вы считаете, что реляционная СУБД лучше подходит для ERP, чем объектно-ориентированная? Просьба дать более подробный комментарий...
3. К слову сказать, ЛОЦМАН - это псевдо объектно-ориентированная СУБД, в своем ядре она реализована на чистой реляционной СУБД - MSSQL или Oracle... И в этом может быть плюс - прямой SQL запрос быстрее решает задачу, чем прохождение по связям и объектам... Хотя и это спорно... Чтобы точно все оценить, необходимо иметь две равнозначные разработки в разных системах и честно их сравнивать, а не заниматься критикой до драки... Даниил, если Вы готовы стать постановщиком задачи и готовы набраться терпения (решение займет не мало времени), я готов попытаться реализовать поставленную Вами задачу в ЛОЦМАНе... После чего Ваши заявления можно будет оценить в реальности... Давайте покажем АСКОНу, в конце концов, как надо работать...
4. Если честно, я практически не видел на рынке реально объектно-ориентированных СУБД, все что я видел - это именно псевдо- системы... В бывшем СССР была шикарная разработка - система ИНЭС - в последствии СУБД НИКА... В ее основе лежала система доступа к данным типа "простое дерево"... Это наиболее подходящая к данному типу СУБД... К сожалению, как и все российское, она не нашла широкого применения, она используется в системе ЕВФРАТ-Документооборот и в некоторых системах закрытого военного характера... Я пытался достучаться до авторов, чтобы узнать в каком состоянии она сейчас, однако не получил ответа... Жаль, разработка была очень перспективная...

[Горбушин Даниил]

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

Для начала предлагаю определиться с терминологией. Малый бизнес - это предприятие с годовым оборотом менее 100 тыс.$ или завод выпускающий 3 вида продукции в кол-ве не более 100 шт. в год
Вопрос очень сложный, т.к. из данной формулировки следует какую систему необходимо выбирать.
Обычно, рекомендуют приобретать ERP-систему не дороже 5 или max10% от годового оборота. Исходя из бюджета можно уже думать: смотреть в сторону 1С, Axapta или купить что дешевле или же разрабатывать самим. Хотя при собственной разработке тоже встает вопрос: Может дешевле было купить коробку у 1С?

2. Даниил, я так и не понял, что Вы хотите сказать? Какой тип БД более подходит под описываемую Вами задачу? Вы считаете, что реляционная СУБД лучше подходит для ERP, чем объектно-ориентированная? Просьба дать более подробный комментарий...

Допустим вы ведете Закупки/Продажи в объектной системе. Вы конфигурируете объект "Заказ (продажи)" со следующими свойствами:
1. Статус: Заявка, Подтверждено, Счет, Отгружено, Отфактуровано, Закрыто.
2. Атрибуты: Клиент, Даты (счет, отгрузка и т.д.), и около 100-150 атрибутов.
3. Связи с: Клиентами, Оплатами, Отгрузками, Счетами-Фактурами, Специфкация заказа (у каждой отгрузки тоже будет своя спецификация)
Это основной перечень для создания в объектной системе заказа. Как потом будут делаться выборки для отчетов, как будут данные обрабатываться, объяснять не буду...

Для реляционной БД все проще:
1. Есть таблицы: Заголовок заказа, Строки заказа, Отгрузки
2. Атрибутов нет, т.к. все свойства в полях таблиц.
3. При создании новых заказов записываются строки в свои таблицы, а не в одну как к примеру в dbo.stMain у ЛОЦМАН.

3. К слову сказать, ЛОЦМАН - это псевдо объектно-ориентированная СУБД, в своем ядре она реализована на чистой реляционной СУБД - MSSQL или Oracle... И в этом может быть плюс - прямой SQL запрос быстрее решает задачу, чем прохождение по связям и объектам... Хотя и это спорно... Чтобы точно все оценить, необходимо иметь две равнозначные разработки в разных системах и честно их сравнивать, а не заниматься критикой до драки... Даниил, если Вы готовы стать постановщиком задачи и готовы набраться терпения (решение займет не мало времени), я готов попытаться реализовать поставленную Вами задачу в ЛОЦМАНе... После чего Ваши заявления можно будет оценить в реальности... Давайте покажем АСКОНу, в конце концов, как надо работать...

В 2003 - 2005 я разрабатывал MES-функциональность (АРМы для диспетчеризации и планирования) используя ЛОЦМАН только как хранилище данных. Когда зашла задача о ежедневной регистрации выполнения операций по производственным заданиям - не раздумывая создал свои таблицы в БД ЛОЦМАН, т.к. при объектном подходе был бы слишком большой объем данных. Так же были созданы свои таблицы для хранения данных планирования.

Если вам интересно - с постановкой задачи помогу. Но здесь главное понять что хочется получить в итоге. Я бы к примеру написал свою БД если речь идет о MES-системе. В разработки смежных задач по бухгалтерии (расчет фактической себестоимости, учет и распределение затрат, всякие остальные проводки) лезть не буду никогда, т.к. все давно уже разработано и для этого есть 1С, Галактика, Axapta (MS Dynamics AX) и пусть они бухгалтерией занимаются...

[YorikER]

Обычно, рекомендуют приобретать ERP-систему не дороже 5 или max10% от годового оборота.

Есть еще одна показательная цифра, общепринятая в мировой практике (было несколько консультаций с IT разработчиками): о покупке ERP системы можно беседовать, если годовой оборот на одного работника предприятия составляет не менее 40000$... Основная проблема машиностроительных предприятий (да и вообще в России) низкая производительность на душу населения: почти в два раза ниже, чем у развитых стран...

Для реляционной БД все проще:
1. Есть таблицы: Заголовок заказа, Строки заказа, Отгрузки
2. Атрибутов нет, т.к. все свойства в полях таблиц.
3. При создании новых заказов записываются строки в свои таблицы, а не в одну как к примеру в dbo.stMain у ЛОЦМАН.

Не буду сильно спорить, у реляционных СУБД скорость доступа к данным (на первый взгляд) быстрее, т.к. читаешь запись с атрибутами... Но есть одна проблема: информационное пространство непрерывно меняется (выходят новые законы, подзаконные акты, новые документы и т.д.)... Возникает проблема с версионностью: каждая новая версия 1С - переформатирование данных, а это серьезная операция, во время которой вы отключаете пользователей от работы... Поддержка обновлений - способ заработка для разработчика, но и головная боль и дополнительные затраты для пользователя, которого вы сажаете как "на иглу"...
Объектно-ориентированные СУБД (ООБД) появились в 80-х годах... Одно из преимуществ заключается в том, что в составе ООБД существует конфигуратор информационного пространства, который позволяет изменять его в online режиме (без отключения пользователей). В Visual Loodsman мы пошли еще дальше - разработали конфигуратор интерфейса с информационным пространством, что позволяет изменять интерфейсную часть ООБД в online режиме. Причем редактированием и разработкой интерфейса могут заниматься сразу же несколько аналитиков, каждый в своей ветке (КПП, ТПП, МТС + склады, производство + планирование и т.д.). Обычный пользователь просто при следующей загрузке окна объекта будет видеть новые поля атрибутов, новые меню, управляющие элементы, представления информации и новые формы документов...
В последнее время к ООБД все чаще обращаются ввиду того, что быстродействие аппаратной части значительно увеличилось и заявленные преимущества выходят на передний план... В реляционных СУБД действительно многие локальные задачи решить проще (с этим я согласен), но в целом (на мой взгляд) будущее за ООБД (или какой-то комбинацией).

Если вам интересно - с постановкой задачи помогу. Но здесь главное понять что хочется получить в итоге. Я бы к примеру написал свою БД если речь идет о MES-системе.

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

[Горбушин Даниил]

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

При подобного рода изменениях переконфигурированием модели данных не ограничешься, т.к. надо еще функциональные модули править.
А в реляционной таблице добавить поля проще простого пишем на SQL-92:
alter table dbo.[Имя таблицы] add
   [Название поля] varchar(15) NULL

[YorikER]

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

Согласен, но я же рассказал про Visual Loodsman (VL) - интерфейс представляется как модель интерфейсных объектов, в структуре интерфейса описаны не только визуальные объекты (формы, поля, кнопки, таблицы, деревья и т.д.), но и функциональные - события и набор базовых процедур (более 50), связанных с визуальными объектами... Кроме этого описаны специальные объекты: DCOM соединения с БД ЛОЦМАНА, системные атрибуты и др. Каждый из этих объектов имеет свое отражение в специальной БД на платформе ЛОЦМАНа. Из них как из "кубиков" моделируется функционал в "online" режиме фактически без программирования... Для этого разработано специальное клиентское приложение. Поэтому основная идея VL - это комбинация моделей данных и функционала... На мой взгляд это наиболее перспективное направление...

[Горбушин Даниил]

...в итоге получается система для програмиста/администратора, а не для пользователя.

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

[YorikER]

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

[Горбушин Даниил]

Возвращаясь к теме, а именно к самому вопросу...

Чертежи на детали ведем в бумажном виде ! В электронном виде чертежи появляются только через сканирование !

Спецификации есть? в ёксель например ли еще где?

2. документы для хранения (в разрезе заказа): чертежи, коммерческое предложение, простейший рассчет нормирования и структуры работ, материалы, оснастка, другие документы  (все документы МС офис)
3. поиск документов в архиве по различным параметрам
4. отслеживание статуса заказа - конструкторская подготовка, нормирование, коммерческое предложение, производство, выполнение
5. интеграция с 1С для подготовки бухгалтерских документов (счет на изделие, накладная и тп).

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

Хотя как бы не ругали меня представители АСКОН, но здесь объективно напрашивается 1С:
1. Архив документов в 1С вести можно, надо только его структурировать правильно.
2. Работа с заказами - здесь надо допилить 1С в сторону связи заказа на продажу со спецификацией изделия, а точнее в строке заказа изделие и допрограмить возможность просмотра состава изделия в архиве.
3. Статус заказа - наверняка в 1С есть статусы заказов. Расширьте существующие и получите желаемое.
4. Интеграцию с 1С как понимаете делать не надо.

Как-то в молодости мне очень хотелось все и со всем проинтегрировать. Казалось что это круто...
Потом я понял, что не надо пытаться что-то запрограмировать или купить ненужный софт, только потому что это модно или потому что задача интересная
.
Любая бизнес задача в первую очередь решается путем рассмотрения бизнес процесса и понимания, что в итоге хочется получить. Подход к процессу с точки зрения процесса задачу не решает, т.к. начинается блуд в плане постоянного совершенствования "ненужных" операций. Я хоть и не сторонник всепригодности системы 6 sigma (Toyota Production System - TPS также извесна как философия Бережливого производства - Lean Manufactoring), но здесь явно покупка PDM - это ненужная операция ("муда").
Сами подумайте, какой вы хотите получить результат... У вас в электронном виде чертежей нет, и как понимаю они еще не скоро появятся - зачем здесь тогда PLM, если достаточно файлового хранилища и структурированного архива.
А вот где создавать этот архив - решайте сами.

[АКн]

Коллеги !

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

В системе 1С версии 8.1 и старше данные вопросы все решены по умолчанию !!!
Ничего делать не надо (по предварительной оценке).
Ранее я имел опыт работы только с версией 7.7 - там это все надо делать.
Остался вопрос конфигурации 1С.

Все другое что смотрел - Лоцман, 1С-PDM, NauDOC для решения нашей задачи больно сложно, дорого и де факто не нужно.

Вот когда будем работать  с чертежами в эл виде и более сложным изделиям тогда будем смотретть дальше.