Возвращаясь к ERP и 1С
Бука
28.05.2002 - 05:30
Недавно я писал, что конторе требуется разработать на платформе 1С систему управления запасами, клиентами, финансами и т.д.
Насколько я понимаю, решение этих задач входит в круг систем ERP-класса.
Понятно, что в 1С можно реализовать некоторую часть функциональности этих систем.
Хотелось бы услышать мнение людей, которые решали подобные задачи, в каком объеме они решались, с какими ограничениями и т.д.
Не хочется здесь устраивать дискуссию по поводу возможности решения этого в 1С, вопрос в другом - какую часть функциональности ERP можно решить средствами 1С.
Stark
1 - 28.05.2002 - 05:50
Хочу узнать, что такое ERP
Бука
2 - 28.05.2002 - 05:55
Вот умные люди проснутся, вот тогда и узнаем
Ради прикола, в Гугле набери "управление запасами" :)
livsoft
3 - 28.05.2002 - 05:56
ERP - Система управления ресурсами предприятия
Худой
4 - 28.05.2002 - 06:58
Проснулся(протирает глаза).
Нуссс...?
Stark
5 - 28.05.2002 - 07:14
Ну вот Бука нам с тобой объяснили, что такое ERP ;)
Бука
6 - 28.05.2002 - 07:25
все понятно ;)
И все-таки .....

7 - 28.05.2002 - 07:45
Ерп это ентерпайз ресурс планинг.управление ресурсами предприятия.
на 1с это не сделать , тк производство на 1С - абсурд. имхо.
а остальное попытаться можно . красивый CRM ты кончено всеравно не придумаешь, а финансковое планирование наверняка напишешь. Проблема в том что твои гениальные изыски не будут востребованны заказчиком..если только заказчик не приставал к тебе с этими задачками в течении уже 2х лет . Или хотя бы месяцев.
Бука
8 - 28.05.2002 - 07:54
Какой тут к черту клиент - ген. директор задачу поставил.
Правда, я тут кое-что у него выяснил в подробностях - никакого тебе планирования запасов, просто отслеживание их уровня на складах, и если что, вопли(программы или отчета) по поводу того, что заканчиваются.
Управление клиентами на самом деле оказалось управлением менеджерами на основе рез-ов их работы с клиентами.
А вот насчет финансового планирования я бы с удовольствием послушал, кто что как решал. Интересно узнать про принциры такого планирования, реализацию как-бы сам сделаю (так или иначе :) ).
BiZ
9 - 28.05.2002 - 08:12
(0)Поищи статьи и учебный сайт Верникова. Yandex поможет. Ссылки не помню.
livsoft
10 - 28.05.2002 - 08:35
(8) Заведи в справочнике реквизит МинОстаток и в отчете Остатки товаров или др. конторолируй его с тем что осталось.

11 - 28.05.2002 - 08:43
Заказчик - это не клиент. Заказчик, это такой человек, который без ВОТ ЭТОЙ ВОТ фмгнюшки жить не может . Если таких нет , то использоваться она не будет. И поэтому даже если вытащишь самую разэтакую схему фин планирования из инета, это будет наверняка не то, что хочет фин отдел. И использовать ее не будет, если тебе не подчиняется. Поэтому фин отдел и должен тебе объяснить , что ОНИ хотят от планирования и какие принципы используют. Не зря же они деньги получают.
А ген директор тебе не задачу поставил, а цель указал. Поставить задачу - это написать ТЗ.
ppson
12 - 28.05.2002 - 10:25
Могу ответить что можно реализовать (и есть реализации) управления и запасами и финансами и CRM. Только спроси от своих руководителей, что они хотят от модуля CRM.
У Инталева есть хорошая фича - управление корпоративными финансами, советую посмотреть, они её пропагандируют и люди там работают неглупые, точнее работали :-)
Управление запасами можно реализовать без всяких проблем
Тот
13 - 28.05.2002 - 10:42
2(7) А почему на 1с не сделать? Вроде, шахматы написали... И кучу игр всяких... Чего по-твоему в 1с не хватает?
ЕRP - достаточно расплывчатое маркетинговое понятие. Это просто лейба, которую желающие вешают на свои программы. Никакого центра, который бы это подтверждал, ннасколько я знаю, не существует. ERP отличается от MRP-II наличием модуля управления персоналом. Что єто такое - каждый волен понимать как хочет. ИТРП утверждает, что их конфигурация соответствует стандарту MRP-II. Значит там все, что просит (0) должно быть.
Где-то не найду у меня была ссылка на ресурс с вопросами, по которым можно определить ERP это или нет. Вопросы просто смешные. По ним комплексная с модулем планирования - вполне ERP.
Птенец
14 - 28.05.2002 - 11:54
2(13)Ай-ай-ай, Тадеушевич! Тебе же молодежь в рот заглядывает, а ты им
"паришь". Самое главное не понимаю - зачем?
2(0)Читайте книги, например, "Управление производством на базе стандарта MRP-II" Гаврилова Д.А. - там все подробно описано. А там уже можно сравнить чего и где из этого (в т.ч. и в 1С) есть...
Lazy Stranger
15 - 28.05.2002 - 12:07
(13) Так ведь шахматы те вроде бы только доску рисовать умеют, играть можно только человек с человеком. Не получится ли и с управлением предприятием на 1С приблизительно тоже самое?
Крокодил
16 - 28.05.2002 - 14:24
2(14) А что тут не понятного по поводу г. Туровского ?
Ну чем можно привлечь на работу за 100 баксов - столько получает основная масса работников в его конторе, в Киеве ? Правильно, только сказками о светлом будущем, грандиозных перспективах и т.д. Ну а выпендриваясь ежедневно на работе, постепенно входищь в роль и начинаешь ездить по ушам всем подряд. Такой вот селявизор (с).
Тот
17 - 28.05.2002 - 14:50
2(16) Какие 100? 80.
А если по-честному - ушел один спец. Но он, правда, давненько на свои хлеба перебрался. Сейчас в Сургуте... Вчера узнал, какая у него зарплата. 5.000 баксов в месяц. В Киеве такого невозможно платить... А попал он туда через контору "Субос" в Киеве. Это СП. Там он наворотил прекрасную систему. А Субос расшифровывается как "Сургут-Бостон". Учредители оттудова... Приехали посмотреть и купили чувака... Думаю, следующим его местом Бостон будет... Так что - есть конфигураторщики, которые 5 штук имеют. Пас я. Правда, он еще и аудитор. Было дело, в конторе одной вставил "Прайс Ватерхаус" по самые... Там он сварганил учет в трех стандартах одновременно. Местном, GAAP и внутрикорпоративном (это дочернее пр-тие крупнейшего в Европе производителя сельхозтехники из Германии)... Такие вот пироги...
Правда, у меня еще один такой есть. Пока работает... Но не за 5 штук, конечно...
VVS
18 - 28.05.2002 - 14:52
(13)"ИТРП утверждает, что их конфигурация соответствует стандарту MRP-II. Значит там все, что просит (0) должно быть."
На сарае знаешь что написано, а там дрова (с) анек
;)
ИТРП сертификацию уже прошло на соответствие стандарту? Если нет, то могут утверждать хоть до посинения - все равно это будет только PR-лапша и ничего более.
Тот
19 - 28.05.2002 - 14:57
2(18) Так на других сараях тоже всякое пишут :)))
Тот
20 - 28.05.2002 - 15:03
2(14) А что я молодежи говорить должен? "Вот там такие люди. Такое написали. Вам ни в жисть... Никогда и ни за что. Тупые вы по-жизни". Тоже вариант. Может разозлю...
Чудес на свете нет! А если есть - то они как раз из этой самой молодежи...
ppson
21 - 28.05.2002 - 15:03
18) Сертификации соответствия MRP II, так же как и MRP, ERP, CSRP и прочие "Р" не существует. Это промышленный стандарт.
ex-Alex
22 - 28.05.2002 - 15:17
Зато ИТПР на ISO 9001 сертифицирована. Правда при некоторых условиях у них процедуры из циклов не выходят :) Не говоря о пачках других мелких багов. Но похоже ISO так и предусмотрено.
Так что про сарай - в тему.
Тот
23 - 28.05.2002 - 15:31
2(22) По ISO 9001 сертифицируется технология обслуживания клиентов, однако. А не программы... Поскольку, я полагаю, ты все же специалист, то должен знать про существование "абсолютно безглючных программ". При определенных условиях...
Такое бывает. Загляни, например, на сайт к Журавлику: "Русский язык - грамотность 100%" http://anj.narod.ru/ так что такие вот пироги...
Крокодил
24 - 28.05.2002 - 15:33
2(17) Странно, я-то всегда считал, что компания "Price Waterhause Coopers"
 - это аудиторская фирма, а Тот просветил, что ее можно кому-то "вставить по самые ...". Наверно для этого надо пофигуратор очень хорошо знать?
Насчет "Субоса". В Сургуте действительно есть такое ЗАО - торгует алюминиевым профилем и прочими стройматериалами. Только ни к нефтегазу, ни тем более к Бостону никакого отношения не имеет. ООО "Субос - Украина", в котором этот чувак чего-то наворотил, разливает в Киеве питьевую воду в пластиковую бутылку, и к сургутскому Субосу, равно как и к Бостону, отношения тоже не имеет.
Тот, у Вас что ни слово, то ложь. А вот что зарплату сотрам теперь платите не 100, а 80 баксов, охотно верю - не зря же набираете вместо программистов недоученных бухов.
ppson
25 - 28.05.2002 - 15:38
23) ИСО 9001 "Система Качества: Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании"
ИСО 9001 является наиболее обширным стандартом; он применим в случае договорной ситуации, когда соответствие специфическим требованиям должно обеспечиваться в течение нескольких стадий, включающих: проектирование/разработку, производство, монтаж и обслуживание.
Так что вы тут не правы
Тот
26 - 28.05.2002 - 15:39
2(24) Так он по аудиту им и вставил. При чем конфигуратор? Про киевский Субос - это точно. Про сургутский - не знаю. А вот с чего ты взял что киевский Субос не имеет отношения ни к Сургуту ни к Бостону - это интересно...
Насчет зарплаты - просто экономим. Зачем же много платить?
VVS
27 - 28.05.2002 - 15:40
(21) Возможно, что это меня так проглючило - спутал может быть с тем же ISO. Впрочем стоит посмотреть на то, что должно быть в MRPII и что есть у ИТРП...
Тот
28 - 28.05.2002 - 15:50
А вообще Крокодил мне очень нравится... Это ж надо - Субос в Сургуте найти! Информированность выше крыши! Может он таким образом на работу к нам попасть хочет?
Тот
29 - 28.05.2002 - 15:56
2(27) Я думаю, смотреть бесполезно. Есть наверняка все. Не зря же они это декларируют. Другое дело - в каком виде. Тут спорить можно. Типа "хи-хи, и это вы называете управлением многопередельным производством". А они в ответ - прямо и в глаза "А почему же нет"? Этим все и кончится... Думаю, с любой другой системой - аналогично.
Крокодил
30 - 28.05.2002 - 15:58
2(28) Нет, просто я считаю, что у нас (в смысле на территории бывшего Союза) одной из основных проблем, почему мы живем хуже чем на западе, является то, что очень часто авторитетом пользуются не умные и грамотные специалисты, а люди, в совершенстве освоившие искусство демагогии.
И яркий пример этого - Вы и отношение к Вам на этом форуме.
Тот
31 - 28.05.2002 - 16:04
2(30) Я думаю, на Западе с этим гораздо хуже. Там существуют целые технологии впаривания. И занимаются им крупные конторы и специально подобраные спецы...
А я - так. Любитель...
VVS
32 - 28.05.2002 - 16:07
(29)С этой точки зрения - и Excel - MRPII.
Тот
33 - 28.05.2002 - 16:13
2(32) А я и говорил в (13), что это все чисто маркетинговые понятия. Вот нет модуля управления персоналом - значит не ERP. А если есть, значит ERP. А в Excel он или Access - нигде же не сказано...
Крокодил
34 - 28.05.2002 - 16:14
Реплика Тота в 31 - яркий пример основных принципов демагогии (наука все-таки).
1. В случае нежелательного развития событий разговор переводится в другое русло. Где собственно речь шла о впаривании?
2. Ссылайтесь как можно чаще на авторитетные источники. В данном случае на крупные конторы и специально подобранных спецов.
Ну и так далее.
Спасибо, Тот, за показательное выступление.
Тот
35 - 28.05.2002 - 16:21
http://www.computerra.ru/offline/2001/419/13770/page2.html
ppson
36 - 28.05.2002 - 16:23
хм. Управления персоналом (в российском стандарте) я пока не видел ни в одной западной системе. однако из-за этого они не стали не ERP системами.
Если идти по терминологии, то MRPII - управления производством. если ты приписываешь к ней модуль, который к производству отношения не имеет, но управляет ресурсами предприятия или дает какую либо информация для принятия решений то почти можно считать что у тебя система выше MRPII. Будет ли она ERP - наверно да. Стандарты (точнее описание систем MRP, MRP II, ERP) подразумевают что системы должны иметь какой то набор фиксированный требований. в одном случае давать возможность управлять чисто складом, в другом - производством. Так как пока ERP - это верхушка этой пирамиды, то все системы выше MRPII - можно назвать ERP. Будем ждать ERP II
26) - Кадры решают все. Скупой платит дважды.
Тот
37 - 28.05.2002 - 16:26
2(34) Пожалуйста. Мозги я парить действительно умею.
Тот
38 - 28.05.2002 - 16:30
http://www.computerra.ru/offline/2001/419/13770/index.html
Здесь начало.
Крокодил
39 - 28.05.2002 - 16:35
2(36) Насчет последней реплики про кадры. Они действительно решают все, если нужно работать. А если у тебя, как у Тот"а, фирма-паразит, существующая за счет "автоматизации" одного клиента, который тратит государственные деньги, а договоры подписываются за счет личных (родственных, национальных) связей, то ... Деньги, отпущенные на автоматизацию, все равно будут получены до копейки, а вот зарплата сотрудникам - это прямые расходы, причем из собственного кармана.
Идиёт
40 - 28.05.2002 - 16:39
Крокодил, обидно что тебя, такого классного, уважают меньше чем Тота, который тока трепется, базы пузом меряет да ПарТоргствует помаленьку?
%)
ppson
41 - 28.05.2002 - 16:39
39) - я вас не понял.
что я хотел сказать двумя своими фразами, так это то что кадрами не надо распыляться (особенно квалифицированными) и платить им достойную зарплату.
Тот
42 - 28.05.2002 - 16:59
Прав Идиёт... Мнея тут за партийную должность уважают. А не за демагогию... Это ж ясно.
2(41) Это ты здорово сказал! Просто совершенно предметно и ново! (без обид. Как ПарТорг я должен такие постинги хвалить).
reminder
43 - 28.05.2002 - 19:21
Не могу понять чем принципиально отличается ERP система на GW-BASIC'e или Delphi или 1С ? Наверное тем же, чем вес килограмма железа от веса килограмма ваты.
Птенец
44 - 28.05.2002 - 20:01
И я не понимаю... Просто не видел ERP ни на одном, ни на другом, ни на третьем. Может, ссылку дашь или на мыло сбросишь? Вот и посравниваем!
Nickolay
45 - 28.05.2002 - 20:21
2(17)-Читал - плакаль! Тот Субос, что Сургут-Бостон (точнее, его однофамилец в Сургуте, обслуживаю сам лично! :))) Хозяина Субоса киевского знаю лично - не станет он платить 150 тыс. руб./мес. за одноэсника - сегодня оформили с одной из его компаний договор на чуть бульше 600$/мес.
Навешали тебе г-н ТоТ по полной программе!!!
Нет конфигураторщиков в Сургуте, которые 5 штук/мес. имеют на одной фирме в Сургуте!
БТР
46 - 28.05.2002 - 20:24
Нет, ну как все-таки всех зазомбировали "крутые/большие" разработчики крутых программ? :)
Сколько общаюсь, пока не слышал реальных проблем по реализации ERP в конфигурациях 1С.
Люди, проблема в том, что ERP-система должна соответствовать бизнес-процессам конкретной фирмы. Есть два подхода к этому. Первый - написать универсальную систему, подходящую для всех и настраивать ее. Второй - разработать заказную систему для конкретного предприятия.
Что такое ERP?
Планирование ресурсов предприятия.
Какие бывают ресурсы?
Финансовые, материальные, производственные и трудовые.
Как происходит планирование?
Создаются списки ресурсов, описываются лимиты (нормативы) их использования, описываются бизнес-процессы, в которых эти ресурсы задействуются, планируются выходные показатели, по формулам рассчитывается потребность в ресурсах. Далее, проводятся фактические операции по тем же бизнес процессам.
Все.
Кто-то знает, что здесь не учтено?
Спорим сейчас каждый полезет в технические проблемы и способы их решения, которые нельзя никак организовать в 1С?
Люди. ERP это не программная среда. Это правильно организованные бизнес-процессы. Сертифицируется НЕ ПРОГРАММА. Сертифицируются ПРОЦЕССЫ.
Если мне сейчас кто-то скажет, что какие-то ВНЕДРЕННЫЕ процессы, которые ИСПОЛНЯЮТСЯ людьми ПО ЧЕТКОМУ РЕГЛАМЕНТУ нельзя автоматизировать в 1С и сможет мне это достойно аргументировать я этому человеку подарю бутылочку замечательного королевского бальзама.
Что я сейчас делаю.
Планирование продаж. Планирование загрузки оборудования. Планирование капитальных вложений. Планирование загрузки персонала. Планирование поребности в сырье и материалах. Планирование затрат на закупки, продажи, производство, управление. Планирование затрат на оплату труда и программу премирования сотрудников. Планирование налогов и отчислений. Планирование закупок. Планирование производственных запасов. Планирование выплат по реструктуризации задолженности. Технологическое нормирование. Факт по всему циклу планирования. Оперативная отчетность. Аналитическая отчетность. Бухгалтерская отчетность по филиалам. Консолидированная бухгалтерская отчетность. Налоговая отчетность. Статистическая отчетность. Производственная отраслевая отчетность перед министирством сельского хозяйства. Финансовая управленческая отчетность. Финансовая отчетность перед акционерами. Финансовая отчетность перед отраслевой бюджетной комиссией.
И ТЕХНИЧЕСКИХ проблем нет. Все вполне вписывается в ИТРП: Производственное предприятие+ 1С: Финансовое планирование + 1С: Зарплата и Кадры + ДеловоеДосье: Персонал + ДеловоеДосье: Клиенты + собственные отраслевые доработки типовых бланков документов и отчетов + доработки для линейной структуры филиалов + собственные модули планирования и учета налогов и общехозяйственных затрат.
Проблемы исключетельно ОРГАНИЗАЦИОННЫЕ. Любимое понятие РЕИНЖИНИРИНГ. Вот и весь ERP. ERP не в коде программы. Он в головах людей, которые работают в организации.
Nickolay
47 - 28.05.2002 - 20:27
2(24,26,28) У Сургутского и Киевского Субосов изначально были одни корни. Теперь разные. В Бостоне раньше покупали кое-что, отсюда и название %))
А правды в словах г-на ТоТа немного :((
toypaul
48 - 28.05.2002 - 21:06
(46) Иииииии..... (сглатывая слюну) ца ;). Где б на такое чудо посмотреть, хотя бы описание (основ) плюс демки (хотя бы картинки, демо-конфу было бы вообще здорово).
Готов вступить в партию
49 - 28.05.2002 - 21:14
>>демо-конфу было бы вообще
2 (48). Объясни мне, идиоту, чем демо-код от рабочего будет отличаться?!
mazzy
50 - 28.05.2002 - 22:25
БТР "...пока не слышал реальных проблем по реализации ERP в конфигурациях 1С... Что такое ERP? Планирование ресурсов предприятия."
.
А как насчет ввода планов будущим числом? Или всю ERP-систему на бухгалтерии делать? :)
 
Тот
51 - 28.05.2002 - 23:13
2(45) Оччень интересно.... Не мог бы ты в Киеве установить со мной прямой контакт? Мне бы очень помогло, что про 5.000 - это миф. Раскрой глаза на мир всем. И мне тоже, pls.
Тот
52 - 28.05.2002 - 23:15
(45) Ты бы мне очень сильно помог, если честно. Я готов рассматривать поощрение в размере 1/5 указанной суммы.
Тот
53 - 28.05.2002 - 23:42
(45) И еще об одном. Мне навешать весьма трудно. Но если Гену там кинули - это еще лишний раз доказательство, что от коллектива лучше не отрываться. Несколько месяцев назад мы обсуждали с ним цифры ВамдимаМ. 800 у.е в месяц. Цифры по Киеву подтвердились. Столько зарабатывать можно. А вот в то, что он кинуть себя позволил.... ну очень мне в это поверить трудно... Факты выложишь - заплачу. Чтоб другим неповадно было....
ОФФ-физика
54 - 28.05.2002 - 23:45
(43) Килограмм железа тяжелеее килограмма ваты. Проверял.
Nickolay
55 - 29.05.2002 - 06:19
2(53) Имя его сообщи мне, и название конторы. Хотя если это действительно через киевский субос, узнаю все из первых рук - их офис на одном этаже с моим. Денег не надо - посмотреть бы на этого человечище, что тут такие бабки поднимает =)).
БТР
56 - 29.05.2002 - 09:43
(50) Зачем на бухгалтерии? Делай аналитику по периодам. Или ты хочешь сказать, что в Аксапте не так ;)
БТР
57 - 29.05.2002 - 09:45
(48) Прости, это не продажная система... Это заказная. Кроме того, у меня есть дальнейшие планы в спиртпроме ;)
БТР
58 - 29.05.2002 - 09:48
(50, 56) уточню на всякий случай, чтобы разночтений не было. Все документы планирования вводятся текущей датой. Сами планы вносятся с аналитикой по периодам исполнения. И по этим же аналитикам закрываются фактом. Не знаю, смотрел ли ты 1С-Финансовое планирование. Если смотрел, скажи, что не так в их модели. Было бы интересно узнать. Помни - бутылка королевского бальзама на кону :)
Jora
59 - 29.05.2002 - 10:11
Хотя Тот и поддерживает идею о ERP на 1С, его же ссылка в (35) скорее опровергает это. И слова БТРа в (57) иллюстрируют это.
В конце указанной статьи есть табличка, показывающая что доля заказных (самописных) систем такого рода ничтожно мала.
В свете указанного - разработать систему класса ERP на 1С конечно можно,
но это будет штучный экземпляр (см. 57). А разрабатывать универсальную систему класса ERP на 1C, ИМХО, это финансовое самоубийство.
Alex_U
60 - 29.05.2002 - 10:23
Разрабатывать универсальную систему на 1С ВНЕ связи с ERP - финансовое самоубийство. 1С - средство для быстрого создания заказных систем.
Alex_SS
61 - 29.05.2002 - 10:31
(60) - Маленькое уточнение к (60). "1С - средство для быстрого создания заказных систем." - немного не так - 1С - средство для быстрого создания дешевых, простых, заказных систем. Расчитанных на ограниченное число рабочих мест с нормальным функционалом или на большее (к>10:12) при условии крайне ограниченного функционала, или без ограничения, но крайне медленная система". А БТР после изготовления своей системы будет Гераклом, который не смогет повторить свой подвиг.
А теперь прикинем зарплату одного БТР, срок изготовления его системы - и решим, ЧТО выгоднее - купить готовую или поддерживать его разработку.
БТР
62 - 29.05.2002 - 10:32
(59) Я так полагаю, разрабатывать универсальную систему класса ERP в Росии на чем угодно - это самоубийство.
Просто, кому-то нужно семиуровневое резервирование товаров при реализации, кому-то нужна многоуровневая система расчета премиальных, кому-то нужна система оптимизации расхода материалов, кому-то нужна экспертная система подбора аналогов материалов и комплектующих, кому-то нужна система учета качественных показателей сырья, кому-то нужна система тайм-менеджмента, кому-то нужна геоинформационная система логистики, кому-то нужна система прогнозов объемов и цен, кому-то нужна компаративная система оценки рисков, кому-то нужна система бюджетирования по критериям и ограничениям, кому-то нужна система управления производственными мощностями, кому-то нужна система технологической статистики, кому-то нужна система вариативного нормирования, кому-то нужна система онлайн продаж, кому-то нужна система онлайн заказов, кому-то нужна система онлайн поддержки менеджеров, кому-то нужна система мониторинга критических индикаторов, кому-то нужна система кризис-контроля, кому-то нужна система поддержки переговоров, кому-то нужна система управления дизайном, кому-то нужна система алтернации производства, кому-то нужна система поддержки управления качеством, кому-то нужна система управления знаниями, кому-то нужна система градиентной поддержки принятия решений, кому-то нужная экспертная система диагностики принимаемых решений, кому-то нужна система анализа недетерминированных потоков данных...
95% этих подсистем могут быть реализованы сотнями различных способов, и из этой сотни каждому предприятию более всего подходит только два-три, и всегда разные. С какими-то модулями реализованными без специализации можно мириться, без автоматизации других можно обойтись, но кто сказал, что крупное универсальное решение это единственный путь?
У 1С своя философия на рынке, своя миссия, свои идеи. И ничто не мешает создавать на 1С системы класса ERP. Уверен, что никому не нужен универсальный идеал. Нужен просто хороший гибкий конструктор, позволяющий внедрять ERP системы в максимально короткие сроки с минимальным совокупным бюджетом на стратегический срок.
И я пока не видел ни одного блестящего решения. Но видел много просто хороших.
БТР
63 - 29.05.2002 - 10:34
Не знаю, можно ли разобраться в ниженаписанном, это так, рабочие размышления относительно проекта "Интегрированная среда проектирования, разработки, сопровождения, администрирования, документирования и использования информационных систем"
Разумеется, тут далеко не все. Но, тем не менее...
--------------------
Основные принципы:
- использование экстремального программирования;
- анализ/проектирование/кодирование/тестирование/эксплуатация в одной рабочей среде
- использование механизма управления версиями и альтернативами
- использование механизма контроля параллельной работы над объектами
- слои разработки: слой обсуждения аналитических решений системы/слой бизнес-процессов системы, слой обсуждения архитектуры системы/слой архитектуры системы, слой обсуждения дизайна системы/слой дизайна системы, слой обсуждения технических решений системы/слой алгоритмов системы, слой обсуждения тестирования системы/слой управления версиями и альтернативами кода в системе, слой обсуждения внедрения системы/слой методологии внедрения и использования системы, слой обсуждения технической документации, системы/слой пользовательской документации системы
- навигация по слоям системе в рабочей среде
- структура слоев: обсуждение (история слоя)/актуальное представление слоя КАК ЕСТЬ/перспективное представление слоя КАК БУДЕТ (с альтернативами КАК НАДО, точками зрения, техническими и принципиальными ограничениями и т.д.)
- точки зрения на систему: аналитическая (представления бизнес-процессов, методология внедрения)/проектная (архитектуры системы, структура метаданных)/дизайнерская (внешний вид системы)/программистская (алгоритмы, код программы)/административная (права доступа)/пользовательская (документация, помощь, методика работы)
Резюме:
Основная идея:
1. Представление точек зрения (ролей)
- аналитика
- архитектора
- дизайнера
- программиста
- администратора
- пользователя
2. Виды (слои) представления:
- история изменений представления (обсуждение, форум, предыдущие рабочие версии)
- актуальное представление (рабочая версия КАК ЕСТЬ)
- перспективное представление (разрабатываемая версия КАК БУДЕТ, альтернативы, представления КАК НАДО, особые мнения, замечания, заявки, вопросы, проблемы, задачи)
3. Организационная и ролевая структура пользователей и разработчиков системы
Jora
64 - 29.05.2002 - 10:55
2(63) Показательный факт - на первом месте стоит экстремальное программирование. В этом вся соль вопроса, почему заказные системы так мало распространены. Ошибка в программе бухучета, исправляемая на ходу по методу экстремального программирования - это одно (в крайнем случае налоговая оштрафует). А вот в контуре управления производством - другое. Ситуация - ошиблись, произвели не 100, а 300 тонн мороженого, а холодильник только на 100. Ну и?
Ну кто-нибудь будет ставить в качестве такой программы бета-версию? А экстремальное программирование - это бета-версии в течении довольно длительного периода времени.
Alex_U
65 - 29.05.2002 - 11:01
(64) Двести тонн - раздать детям!!! :)
БТР
66 - 29.05.2002 - 11:04
(64) "Вы просто не умеете их готовить"
Вообще-то, экстремальное программирование это слишком молодая методика, чтобы так быстро делать выводы.
Я могу привести контраргументы. Во-первых, никто не гарантирует от ошибок проектирования и даже анализа. Но при работе по каскадной или по спиральной методикам эта ошибка будет обнаружена через гораздо более длительный срок.
Экстремальное программирование вовсе не исключает ни этапа анализа, ни этапа проектирования. Весь смысл в том, что все аналитические и проектные решения проверяются гораздо раньше, чем по классическим методикам. Соответственно раньше тестируются и раньше исправляются.
Stiw
67 - 29.05.2002 - 11:22
Платформа 7.7 предназначена для мелких и средних предприятий.
(с расчетом по количеству транзакций).
А ERP решения это для крупных предприятий
(в полном функционале).
Частные решения по переносу функционала входящего в неформализованный ERP стандарт на платформу 7.7 возможны и есть тому многие доказательства.
НО полное, комплексное решение невозможно по двум причинам:
1. Ориентированность платформы на учетные цели (читай бухгалтерские).
2. Невозможность корректной работы будущим числом.
3. Слабый внутренний язык.
4. Ограничение по размеру файла конфигурации.
5. Слабые средства администрирования.
И все попытки создания подобного функционала обречены.
Рекомендую посмотреть решение ИТРП+Инталев чтобы понять насколько всё не просто.
А еще рекомендую поискать хотябы одно работающее на данном монстре предприятие, с уровнем внедрения хотябы 70%
Stiw
68 - 29.05.2002 - 11:25
Хотел написать две причины,а написал целых пять :)
Constantin
69 - 29.05.2002 - 11:31
(67) И какие ограничения по размеру файла конфигурации?
Jora
70 - 29.05.2002 - 11:33
2(66) Наверное нет смысла вдаваться в теоретические дебаты по поводу экстремального программирования. Я лишь хотел сказать то, что Ваша конфигурация, написанная на заказ, ничем не отличается от таких же самописных АРМов на Клиппере, Дельфи, Бейсике (каким бы высоким не было их качество). Все они занимают свою определенную нишу, за пределы которой не выходят (хоть при экстремальном программировании, хоть при классическом, реализуют они ERP или нет).
И они никогда не являлись конкурентами серийных продуктов. 1С занимает нынешнее положение на рынке не за счет тьмы самописных конфигураций, а за счет типовых, какими бы они не были. И ни одна сторонняя фирма или коллектив, пишущие конфигурации под 1С, не будут играть значительной роли на рынке систем управления предприятием.
БТР
71 - 29.05.2002 - 11:38
(67) Можно я повозражаю?
Во-первых, я не слышал ничего о том, что ERP может называться только та система которая рассчитана именно на какое-то большое количество транзакций. Честно, не слышал. И что такое неформализованный ERP стандарт? На мой взгляд, формальный стандарт достаточно очевиден, чтобы был смысл его передергивать.
Во-вторых, что касается учетных(бухгалтерских) целей. Не вижу проблемы. Если можно, поподробнее о сути проблемы.
В-третьих, что значит невозможность корректной работы будущим числом? Делаешь измерение регистра или субконо типа дата, и пиши туда какие угодно будущие числа.
По пункту 3, относительно слабого внутреннего языка. Не совсем понятно, какое отношение это имеет к ERP. Версия SQL92 имеет еще более слабый язык. Но, выходит один слабый язык подходит, а другой нет?
По пункту 4, тоже не очень понял. На что влияет ограничения файла конфигурации и как это связано с ERP?
По пункту 5, да, внутренние средства администрирования ограничены. Но не более ограничены, чем средства Oracle или MS SQL. И уж наверняка на порядок больше чем в Visual C++ :), прошу прощения за банальность.
И опять же, я посмотрел решение ИТРП+Инталев. Мало того, я практически его и внедряю.
И еще, по поводу уровню внедрения. Относительно чего считать процент уровня внедрения? На мой взгляд это самый истеричный подход. Потому что чаще всего считают относительно уровня предпроектных ожиданий руководства заказчика, не так ли? Так что весь вопрос лишь в том, чтобы правильно вести ПРЕДПРОДАЖНЫЕ переговоры.
----------
Ну зачем все проблемы валить в одну кучу, а потом эту кучу без разбора валить на больную голову 1С? Точно так же можно все проблемы валить на больные головы Паруса, Галактики, Интеллект-сервиса, Навизион, САП, Баан... Может уже хватит голосовать списком?
Вера в то, что все попытки обречены это слишком пессемистично.
Давайте обсуждать конкретные проблемы. А потом уже делать комплексные выводы. С общефилософской точки зрения в моей голове хватает моих собственных теоретических вопросов, мнений, выводов, сомнений, рефлексий. Полагаю, каждый может сказать о себе то же самое.
Может быть все-таки продолжим борьбу за бутыль королевского бальзама?
БТР
72 - 29.05.2002 - 11:45
(70) Стоит ли переходить на личности, не зная фактов? Вообще-то я делаю заказную систему из типовых модулей. И намерен оставить максимальную обновляемость. Что касается разницы между кустарными АРМами и заказной ИНТЕГРИРОВАННОЙ системой, то она, на мой взгляд очевидна. Что касается коробочных продуктов (серийных), повторюсь еще раз, я за набор типовых кубиков, которые легко интегрируются, и против тяжеловесных универсальных параметрических систем.
Кроме того, я уверен, что необходима комплексная оценка интегрированной информационной системы от процесса анализа бизнес-процессов до долгосрочного сопровождения. На мой взгляд, организация процесса внедрения это 80% успеха. И для меня гораздо более важно то, что я могу внедрить от начала и до конца, а не то, насколько распространена данная типовая конфигурация. Уж если мы говорим о рынке ERP-систем, то давайте не будем выдергивать аргументы из рынка мелких типовых систем.
Stiw
73 - 29.05.2002 - 12:08
2(71) Возражать даже нужно, но это ничего не изменит.
И называть можно что угодно как угодно суть от этого не изменится.
Ниша 1С малые и средние придприятия.
Про позиционирование ИТПР дословно:
"Программа является готовым решением для комплексной автоматизации средних и малых предприятий, крупные предприятия
могут ее использовать в качестве основы при построении информационной системы управления".
Под основой в данном случае понимается макет.
МД более 10 метров на платформах NT не объединяется и работает медленно, а линейку 9Х закрыли.
Размерность файла конфигурации не позволит создать полноценное ERP решение в рамках одной конфигурации, а лоскутную автоматизацию мы уже проходили.
Процент внедрения нужно считать от полного функционала системы.
А истерии никакой нет. Более того сам работаю на ИТРП :)
maxlab
74 - 29.05.2002 - 12:08
to БТР... Привези бутыль в Красную поляну :-) Разберемся ...
vin
75 - 29.05.2002 - 12:46
Я считаю проблема не в выборе программы, а в людях которые с ней будут работать.
Мы работам с 1С около двух лет, а многие бухгалтера типичные свои ошибки находить так и не научились или еще лучше, говорят, что вы нам должны сказать какие проводки надо делать чтобы итоги были правильные практически требую обучить бух учету. Бухов у нас порядка 100.Теперь представьте, что то же самое будут говорить все пользователи которые будут работать с ней, а их станет на порядок больше. Еще на крупных предприятиях идет сильная децентрализация работ, один человек ведет одно направление и больше ни кто (взаимозаменяемость не проходит, саботируется). Вот этот человек увольняется и пошел завал, а если уволился руководитель который пинал своих подчиненных и контролировал то вообще хана. Мое горькое мнение, что если хочешь внедрить серьезный продукт половина людей должна быть программист тире еще кто-то или берешь 1С и растишь пользователей.
VVS
76 - 29.05.2002 - 12:47
(73)
"линейку 9Х закрыли"
И Win9Х внезано перестали работать?
Ну и для СИСТЕМЫ без разницы - лоскутная она или нет. Если лоскутов немного и связи между ними хорошо продуманы - почему бы и нет? Во всяком случае модуль зарплаты практически всегда реализуется отдельно(будь то ЗиК или Камин).
Stiw
77 - 29.05.2002 - 12:58
2(76) И DOS до сих пор продолжает работать :)
Думаю что ERP подразумевает целостность в едином информационном пространстве, так что реализация отдельного лоскутка останется за 1С.
А ещё кажется мне, что ERP и одиночка разработчик несовместимы не по ценовой категории, не по соображениям разумности.
Тот
78 - 29.05.2002 - 13:04
(73) Опять за рыбу деньги. ДЛЯ МАЛЫХ, и все тут!
И с (62) "Уверен, что никому не нужен универсальный идеал. Нужен просто хороший гибкий конструктор" не согласен. Заказчику не нужно ни то, ни другое. Ему нужно решать определенные проблемы в своем хозяйстве. И если их в приемлемые сроки и за приемлемые деньги можно решать, ему совершенно не важно - есть там лейба ERP, другая, или вообще ее нет.
Я считаю, что 1С породила принципиально новую технологию автоматизации. Достигнуто это методами, которые я называю "пиратско-пионерские". Т.е. создана Народная среда разработки автоматизированных систем. Это принципиально. Настолько, что SAP тоже хочет, по-видимому, создать что-то подобное.
Для меня 1С это не конфигурация. И даже не платформа (7.7 не вечна). Это именно технология, насыщеная специалистами и пользователями.
Jora
79 - 29.05.2002 - 13:21
2(72) То что Вы делаете свою систему на основе типовых модулей, нисколько не улучшает ее качества (качество самих типовых оставляет желать лучшего). И так поступают большинство разработчиков крупных заказных систем на базе 1С - ресурсов на такую разработку с нуля у большинства просто нет. Тем, собственно, 1С и привлекательна для таких разработок - есть возможность быстрого старта и можно сразу показать макет системы.
Ну а потом. Потом начинаются проблемы. Можно посмотреть на комплексную конфигурацию от 1С. По сравнению с остальными типовыми качество значительно ниже. Тут кстати и заканчивается, почему-то, легкая интеграция "типовых кубиков" (у допотопного БЭСТ-4 отдельные модули объединялись в интегрированную систему куда легче - странно, правда?). Да, 1С нашла выход - предлагает комплексную поставку, набор разрозненных модулей - но это возврат к лоскутной автоматизации.
Тот
80 - 29.05.2002 - 13:35
Прежде чем о чем-либо спорить - надо договориться о терминах.
(79) Что такое "качество"? Как ты его меряешь? Что такое "лоскутная автоматизация"?
А в целом - если система решает стоящие перед ней задачи, она качественная. И "лоскутная" или (какая?) - кого это волнует? Разработчика? Эксплуатирующую организацию?
Jora
81 - 29.05.2002 - 13:44
2(80) Тот, не надо заниматься демагогией. Я думаю, ты прекрасно понимаешь, что такое качество и чем комплексная автоматизация отличается от лоскутной.
Я тоже могу, как и ты, ставить риторические вопросы - "а что такое система?, а как ты определяешь решает ли система задачи?, и надо ли их решать?"
И изрекать банальные истины - "Автоматизация - не самоцель. Главное - результат. Больше товаров, хороших и разных!"
Крокодила - в студию.
ex-Alex
82 - 29.05.2002 - 13:45
Думаю, что мух все же стоит отделить от котлет. БТР прав по большей части. А точнее - 90% нынешних проблем предприятий - от безумного понимания бизнес-процессов и руководства. Самое маразматичное - все большая часть этих боссов имеет экономическое образование. Но как раз им и сложнее всего доказать, что для управления нужно применять экономические методы. Но...
1С - все же убогая платформа даже для среднего предприятия. Это мое убеждение и никто еще мне не доказал обратного. 20 активных пользователей в одной ИБ для нее - предел. Те, кто сейчас попытаются меня опровергнуть - не спешите. У меня их бывает 65 в хорошие дни - так что некоторый опыт есть. Дробить базу - значит порождать массу проблем с синхронизацией и актуальностью данных. Для "посмертного" учета (которым и занимаются большинство моих оппонентов) вроде и ничего, но для оперативного управления - смерть. Это тоже факт. Упрощать функциональность для достижения производительности - тупиковый вариант развития. Попробуйте "навернуть" базу - использовать механизм свойств ТМЦ, многовалютный учет, разделите учет по типам и фирмам, сделайте систему резервирования с возможностью ручного управления резервами - и ваша ERP от v77 загнется. Я не говорю уже про логистику и производство (не элементарное производство, в котором на входе зерно, а на выходе спирт). Связано ли понятие ERP с размером предприятия и производительностью ИС? Напрямую нет. Но ERP предполагает нормально функционирующее предприятие, с отлаженными бизнес-процессами, с правильными подходами к управлению. Т.е. вряд ли это ларек. Вот вам и связь.
Причина низкой производительности понятна - так и было задумано. Причина безумного механизма блокировок тоже ясна - в DBF по другому практически не сделать. Кто-то это оспорит? Или от хорошей жизни прямые запросы, OLAP, репликация баз для отчетов?
Сильный или слабый язык? Вопрос неоднозначный. В нем легко сделать то, на что он рассчитан. Но шаг вправо-влево - расстрел. Неверующие - читайте этот же форум. И про многотабличные документы, и про периодические реквизиты в запросах, тормоза на вложеных запросах, отборы в журналах, обработка событий и т.п. Удаление строк из ТЗ, наконец :) Или от хорошей жизни развиваются разного рода внешние компоненты?
Хороша ли корпоративная система, в которой можно путем сноса userdef получить доступ к данным? Или требуется выгнать из базы всех пользователей, чтобы подкорректировать кому-то права?
Спасут ли "буржуйские" КИС наши предприятия? Вопрос еще более неоднозначный, чем "спасет ли их 1С?" Думаю, что есть конкретное предприятие "Рога и копыта" с конкретными требованиями к автоматизации, которому нужна конкретная КИС. И внедрять ее будет конкретный внедренец. Прошу произносить правильно "кОнкретный", а не "кАААнкретный". Так что наши изыскания по существу флейм.
ЗЫ - я не любитель королевского бальзама. Более того - с таким подходом можно и на EXEL создать ERP систему. Тут спорить сложно.
vin
83 - 29.05.2002 - 13:47
(79)<но это возврат к лоскутной автоматизации> а мы говорим своим руководителям: "Пусть будут лоскутки.", но довайте посмотрим хоть в 1С приближении, что мы хотим получить и как это будет выгледить, да и опыт будет в понятиях, что это такое ERP или MRP-II и дешевле будет.
Stiw
84 - 29.05.2002 - 14:26
Для быстрого старта и определения бизнес-процессов 1С подойдёт, но как только процессы описаны (или не описаны, а просто работают),а предприятие продолжает расти нужно быстренько управленческую базу (та которая кОнкретные деньги считает) также быстренько куда-то переносить.
Платформу и поставщика решения прийдётся выбирать.
vin
85 - 29.05.2002 - 14:40
(84)Здесь как повезет. Но все будет восновном зависить от вас. Будете сами принимать участие во внедрении результат будет, а если все отдадите на откуп сторонней фирме скорее всего разругаетесь и все будете сами делать.

86 - 29.05.2002 - 14:47
2(85) :)) а как иначе?
телепатов нигде нет , не только среди 1С ников.
vin
87 - 29.05.2002 - 14:53
(86)Есть опыт. У нас 1С:Зарплата внедряли, внедряли а потом создали отдел АСУ и внедрение завершили.
БТР
88 - 29.05.2002 - 14:56
Уже хорошо. Да, действительно, архитектура типовых конфигураций рассчитана на малые предприятия. И, действительно, это архитектура серьезно ограничена особенностями платформы.
Но все-таки, вопрос в большей части, касается функциональности системы, а не технических вариантов реализации архитектуры. Ведь в 1С все-таки есть возможность подключать и внешние компоненты, и использовать прямые вызовы к SQL. Есть возможность писать собственные механизмы идентификации, есть возможность делать внешние отчеты и обработки, есть возможность связывать конфигурации по OLE.
То, что 1С в своих типовых конфигурациях этого не использует (что естественно, ведь 1С не ориентируется на разработку продуктов ERP-класса), не значит, что эти возможности вообще использовать не стоит.
Например, можно разработать конфигурацию так, что вся структура данных (строго нормализованная!!!) будет находится в конфигурации, а весь (!!!) дизайн во внешних обработках, отчетах и формах ActiveX внешних компонент, со всем положенным контролем версий и альтернатив.
maxlab
89 - 29.05.2002 - 15:16
2(88) А глюки платформы где будут? Меня, например, напрягает то что, нет возможности контролировать или вмешиваться в работу движка V7. Поэтому,имхо, на сколько бы ни была бы совершенна конфигурация отвечающая перечисленным выше требованиям (это в принципе реально), работать безупречно все это хоз-во однозначно не будет. Не стОит забивать себе голову чепухой о всевозможности платформы. Теоретически - да... практически - нет.
Stiw
90 - 29.05.2002 - 15:31
2(88) Больше разных великов в массы! А не посчитал во что выльется разработка подобного монстра? И как он будет работать? А не проще ли купить другую платформу?
БТР
91 - 29.05.2002 - 15:50
(89,90) Глюки есть и в других платформах. И не во все ньюансы работы движка можно влазить даже в дельфях. Тем более, когда идет работа с базой данных, 80% глюков создаются нестыковками библиотек... Это мой личный опыт. Не видел еще ни одной системы, в которой было бы качественно меньшее количество глюков, багов и надуманных фич, чем в других. Во всех системах есть проблемы. Это не препятствие для того, чтобы вести в этих системах разработки. В любой профессиональной тусовке хватает и нытиков и энтузиастов. И все мы периодически бываем и теми и другими.
maxlab
92 - 29.05.2002 - 16:19
2(91) Отчасти ты конечно прав. Возможно в Дельфях с их БДЕ именно так и происходит... Не знаю... До знакомства с 1С я работал с VFP (FP) и глюки в основном были мои :-) Ошибки системы это около 5-10 процентов от общих отказов даже если работаешь с сервером через ODBC (RemoteViews в фоксе). Это мои субъективные наблюдения... Но чем хороши классические инструменты, так это тем что ты можешь залезть в свои же собственные дебри (алгоритмы работы с БД) и быстро выправить дефект, что не скажешь об V7 или аналогичной платфоме. Поэтому я всегда высказывал свое имхо по поводу - 1С хороша для моделирования на небольших объемах данных... А потом, клаву в зубы и вперед... реализуем туже функциональность но на традиционном (для кого какой) инструменте. Другое дело что, с выходом на свет V7, масса народу потеряла, или сейчас теряет, свою квалификацию спецов по базам данных как таковых. Соответственно, рабочая сила дешевеет...На 1С слепить что либо легче чем на том же фоксе или дельфях. Это прискорбно.
mazzy
93 - 29.05.2002 - 16:31
БТР, а я думал, что ты пошутил.
.
Мдя... малые-большие... да причем тут размер?
.
Речь идет о принципах и о базовых понятиях.
О ЕРП системе на 1С нельзя говорить до тех пор пока система:
1. не поддерживает будущие проводки (или делает это через зад)
2. не работает со временем (нет такого типа и функций для его обработки)
.
Какое планирование? Вы о чем?
Какое производство, блин, если техпроцессы задаются с точностью до дня (альтернатива - через зад - все указывать в целых минутах или секундах)?
.
БТР, конечно, можно привести и Вихоревский аддон, и радугу и toysql приплести... Но тогда приведи полный список необходимого. И будет ли 1С после такихдобавок 1Сом?
.
БТР, я был просто уверен, что ты пошутил...
maxlab
94 - 29.05.2002 - 16:33
в догонку... А на счет нытиков - это врядли. Здоровый скептицизм - это да. Комплекс по автоматизациии процессов - это ведь не "фивти-мивти". Слишком ответственная штука от безупречной работы которой зависит жизнь предприятия... Не так ли?
ex-Alex
95 - 29.05.2002 - 16:49
То 88. Внешние компоненты - не решение проблемы. Более того - усугубление ее. Как решить проблему блокировки через внешние компоненты? Дело то не в интерфейсе - меня он устраивает и сейчас. В конце концов это не дизайнерская программа. Дело в самом узком месте - структуре данных, механизме трансляции запросов на язык SQL, блокировках. А OLE - еще тот мастдай. Попробуй плотнее с ним поработать - кроме мать-мать-мать ничего не скажешь. То нельзя, это нельзя, там отвалилось, тат не отладить!
А уж слово "строго нормализованная" у меня вызывает только улыбку. Собственно по этому поводу мы уже когда-то спорили. и тогда я приводил конкретные примеры, причем на целую страницу. В v77 данные не находятся даже в первой нормальной форме - это факт, о котором мне спорить не хочется.
Про глюки я не говорю - они действительно у всех. Я также не говорил, что на 1С ничего нельзя пытатся что-то делать.
Единственное, что я хочу сказать - для построения функционально сложных систем платформа очень слабая. Сложно, естественно все посчитать (ну не моего уровня это дело), но думаю есть некий предел, после которого стоимость разработки, эксплуатации и в конечном итоге финансовых потерь от использования превзойдет стоимость решения на более дорогой платформе. С учетом того, что функциональность уже готовых наработок на ней гораздо выше типовых от 1С.
Хотя еще раз с тобой соглашусь - большая весомая часть проблем в головах, а не платформе.
БТР
96 - 29.05.2002 - 17:32
(93) Ну, ты почти прав. Я не слишком серьезен, скажем так :) Но ведь и в каждой шутке есть доля шутки. Я в самом деле, хочу выяснить серьезные платформенные ограничения, которые обоснованно и объективно необходимы для реализации систем класса ERP. Честно скажу, я не считаю технические ограничения проблемой. И я, пожалуй соглашусь с maxlab по поводу того, что 1С это хорошая система для первоначального моделирования, а затем критические модули желательно реализовывать на более низкоуровневой платформе.
Теперь к твоим 1 и 2.
Что касается будущих проводок. Приведи мне пожалуйста пару ситуевин, когда это необходимо и обосновано. Я думаю, это просто одно из технических решений, причем, с аналитической точки зрения - не самое лучшее.
Что касается работы со временем. Лично я в производстве предпочитаю не спускаться слишком глубоко. Это очень необоснованно. Всегда существует объем данных, которые мастера и технологи в состоянии вводить оперативно, не отвлекаясь более чем на 15% от основной работы. Этим и ограничивается глубина контроля технологических операций. А если говорить об автоматических линиях, то в аналитической системе нужно иметь два вида информации: сводную попроцессную и статистическую по критическим показателям мониторинга. Ну не может цепочка из 5-7 человек (вертикальная цепочка управления, большая по длине уже не оптимальна) обработать больше чем 30-40 ключевых индикаторов. Ты можешь описать бизнес-процесс, который формирует более 100 разнородных независимых показателей, которые необходимо контролировать чаще, чем три-четыре раза в день и, одновременно, сохранять эти показатели для следующего уровня управления? Хотелось бы услышать, если такой бизнес-процесс существует.
Понимаешь, я ориентируюсь на то, что в каждой внедренной ERP системе существует регламент работ, который люди могут исполнять без перенагрузки даже при полном критическом сбое системы. А ведь люди в состоянии обрабатывать не так уж и много транзакций. Поэтому, теория ERP утверждает, что правильная реорганизация datawarhouse-processes (е-мое, как же это на русский перевести... информационно-насыщенных процессов, пожалуй) с отсечением аналитики по уровням компетентности позволяет снизить нагрузку на документооборот между уровнями управления до 100 раз. (Только не просить источник, я, разгильдяй, не имею привычки сохранять ссылки)
И я в это действительно верю, хотя бы потому, что ощущал это в своих проектах. Пока руководитель не доверяет полученной сводной информации, ему подавай расшифровки. Но когда он может получить первичную детализацию (10-12 статей) по любому из своих индикаторов (опять же, 10-12) то проблема сразу снимается и сложные отчеты становятся мертвыми. У меня их накапливалось до 100 неиспользуемых из 110 разработанных.
Поэтому сейчас я стараюсь доказывать правильность данных правильностью и прозрачностью методики их формирования. Когда руководитель видит полный регламент подготовки информации уровня поддержки принятия решений, он спокоен за то, что ему приносят.
"А улучшать можно до бесконечности. До бесконечности можно улучшать" (С) А.Райкин
Суть-то в том, что система должна быть понятной людям. А ERP она или нет - разница, в конце-концов важна только продавцу.
IgorKL
97 - 29.05.2002 - 17:32
2(24) Price Waterhause Coopers может и аудиторская фирма, но занимается реинжинирингом. В особенности постановкой учета. А работають там, в основном, наши программисты, с разной степенью крутизны... Так чта...
Про ЕРП: можно и на 1С, и на си, и на ассемблере. Универсальную (более-менее) ЕРП систему на 1С написать невозможно, а заказную - вполне возможно. При чем, если задача будет поставлена правильно, она будет внедрена быстрее и значительно дешевле "монстров". Но: кто скажет, где внедрена в СНГ ЕРП-система относительно быстро, безболезненно и эффективно? Я придерживаюсь мнения, что _пока_ эти системы нам не подходят. Не доросли мы. Буржуи на работе сидят ровно 8 часов, они на три месяца вперед знают, что будут делать по днях. А у нас?
mazzy
98 - 29.05.2002 - 18:09
К БТР (96):
1. будущие проводки - для планирования. Иные решения (ты приводил одно из них) достаточно надуманы. Т.е. вместо нормальной записи в регистр и анализа по регистру выдумывается непонятно что.
.
2. Время нужно для планирования производственных процессов. ...Написал много и стер... если знаешь, то знаешь.
.
Т.е. планирование, планирование, планирование.
.
Давай завершим дискуссию? Никчемная она.
Nickolay
99 - 29.05.2002 - 18:37
2(Тот) Вынужден взять свои слова обратно.
Парень по имени Гена действительно работает в одном здании со мной.
Сам с ним не встетился, не было времени. Но его нам представили как финансиста, который на два порядка круче всех одноэсников. Работает не на одну контору, и учитывая кто о нем так отзывался, заявленная сумма не является невозможной (хотя на мой взгляд все-таки завышена).
Uncle Bens
100 - 29.05.2002 - 18:40
Успел?
БТР
101 - 29.05.2002 - 18:51
1. Я просто убежден, что все проводки должны делаться текущим временем. Это основа основ учета и контроля. А вот как раз ввести контрольную аналитику по сроку - никто не мешает. Более того, если тебе нужно планировать операцию на конкретный день - нет проблем, ты введешь дату. Но если тебе нужно запланировать операцию на пять дней, какую дату ты выберешь? Как ты будешь анализировать разрыв, если запланирована операция на одну дату, а исполнена в следующую? Так что ничего не надумано. Планирование необходимо вести с аналитикой по периоду.
2. Ну хотя бы один пример? Я ведь остаюсь в убежденности, что это просто каприз.
А дискуссия не такая уж и никчемная. Лично я готов избавиться от мифов в своей голове. Почему бы не обсудить конкретные ситуации, а не абстрактные общие положения?
ZhV
102 - 29.05.2002 - 18:55
2 Mazzy
Если не влом писать ...
А насколько соответствует "классу" ERP - Navision/Attain/Axapta ?
Так вкратце - на 15 строчек ?
Знаю ,что есть axforum , но все же..
Тот
103 - 29.05.2002 - 19:44
2(97) Про Прайс Ватерхауз - речь шла о "вставке" именно по части аудита. Насколько я помню, начисление курсовой разницы. Прайс настаивал, что программа рассчитывает ее неправильно. Мы доказали, что они слабо владеют этим вопросом.
Всем остальным: А знаете в чем дело? Вы говорите не про 1С, а про 1Сv7.7, а для меня єто не принципиально.
2(99) Передавай ему пламенный привет. И спроси, что делать с его сертификатом по 1С, который на нашу фирму зарегистрирован...
Pusk
104 - 29.05.2002 - 20:18
to (103) Ты что думаешь, прайсы суперчеловеки какие-то? Они и нас недавно проверяли. И тоже вопросы задавали. И про суммовые и курсовые разницы тоже. если что-то не понятно, то они просто спрашивали и получали грамотные разъяснения. В основном бухи разъясняли. Если что непонятно было, то бухи к программиста обращались по вопросам технического характера (округление при пересчете по историческим курсам и т.п.).
Тот
105 - 29.05.2002 - 21:27
2(104) Я последнее время вообще не думаю ни о чем, окромя партейных обязанностей. А раньше, в допартийной жизни, я постоянно думал: ну почему им платят 100 баксов в час, а мне - нет. Чем наши конфигурации от R/3 отличаются? Почему в цене такая разница? А теперь не думаю...
mazzy
106 - 29.05.2002 - 21:28
БТР 101: "Я просто убежден, что все проводки должны делаться текущим временем. Это основа основ учета и контроля."
И плановые?
"А вот как раз ввести контрольную аналитику по сроку - никто не мешает."
А как же стандартный механизм запросов и итогов? А как же "чудесная" точка актуальности? Т.е. надо делать запрос по всему периоду деятельности по аналитике? А скорость?
.
"Но если тебе нужно запланировать операцию на пять дней, какую дату ты выберешь?"
уводишь в сторону? Вопрос не об этом. Вопрос что делать, если выбранная дата находится в будущем... Например, обе даты в следующем месяце. А уж потом поговорим какую.
.
"Планирование необходимо вести с аналитикой по периоду."
Тогда для план/факта:
= ты не можешь использовать точку актуальности
= придется делать запросы по всему периоду деятельности
= не работают штатные механизмы оптимизации в 1С (даже те, которые есть)
.
"2. Ну хотя бы один пример?"
= Операция выполняется хх минут.
= Станок надо останавливать на профилактические работы каждый час
= Рабочий обедает час с хх:хх до хх:хх
= работа идет в несколько смен. Время начала и окончания смен задано.
= рано утром и поздно вечером производительность падает определенным образом. время задано.
= когда надо начать работу, чтобы изготовить заданное количество деталей.
= если детали надо изготовить в минимальные сроки, то каковы будут затраты на ночные доплаты?
.
Еще пример, программистский. :)
Напоминатель средствами 1С. Функция, напомни через хх минут.
.
ZhV 102:
1. международная версия соответствует
2. чего нет в стандартной версии
= разноска разных складов на разные бух.счета
= оптимизация выбора между несколькими поставщиками
= оптимизация загрузки нескольких одинаковых рабочих центров (календарно-СЕТЕВОЕ планирование)
= оптимизация выбора альтернатив в спецификации
остальное на axforum'е, лады?
 
Шаров
107 - 30.05.2002 - 03:03
Не удержался.
 
V7 - это система моделирования, реализующая высокий уровень абстракции объединяя структуру данных, бизнес-логику и интерфейсы. В синергетике этого объединения преимущества и недостатки. Это понятно.
 
1. Если понимать типовое решения, как кубик заказной системы, то это - подняться еще уровнем выше. Это супер, но не задумывалось авторами типовых, да и платформы. Поминая Брукса, скажу, нужен интерфейс метапрограммирования. БТР, интересен твой опыт в этом.
 
2. Можно пойти по пути расчленения, и все ради "быстро работало". Например, как в последнем абзаце (88). Но, это – понизить уровень абстракции и потерять преимущества V7. (Пытаюсь думать в сторону ToySQL, как добавляющую еще одну абстракцию – абстракцию реляционных таблиц.)
 
В реальной жизни будет компромисс 1 и 2. Его можно назвать ERP ;)
 
Про форум в (63) – это еще теория или уже работает? Не думаю, что нужно сильно специализировать работы, роли и членов команды. А то потом придется реинженирить.
.
108 - 30.05.2002 - 10:49
up
ppson
109 - 30.05.2002 - 10:56
Люди!!!
а что вы хотете друг другу доказать то???
.
110 - 30.05.2002 - 15:53
up
undefined
111 - 30.05.2002 - 17:19
Думаю, что решение задачи лежит в плоскости "кто будет делать-что им нужно". В этом случае сама задача уже не играет роли. Дилетант завалит и учет на складе.
undefined
БТР
112 - 30.05.2002 - 18:39
(109) Доказать? Хм. Ну, например, я полагаю, что суть ERP-систем в организационной методике. И мне кажется, что технические вопросы не занимают главенствующей роли. Пытаюсь ли я это доказать? Неа. Я это постулирую. Не знаю как доказывать. Пробую доказать от обратного. Прошу людей привести технические вопросы безусловно важные для создания ERP-системы. Вдруг такие есть, а я, наивный, их недооцениваю? :)
(107) В 63 - теория. Пока ничего подобного не видел. Ну, разве что BPWIN+ERWIN+что-то-там-еще. Или аналогичные системы. Но есть проблема. Ни одна из этих систем не сохраняет возникающих проблем и вопросов и путей их решения. Нет истории изменений и актуализации. Нет обратной связи от изменяемого кода к аналитической системе. Нет поддержки сопровождения системы. Нет поддержки администрирования системы.
Я так полагаю, что метода должна быть такой.
Аналитики обсуждают модель бизнес-процессов, какие-то части модели принимают раньше, какие-то позже, какие-то передают в работу проектировщикам (архитекторам), какие-то передают в работу дизайнерам. Проектировщики, заходя в свои слои видят списки задач и вопросов, поставленные аналитиками, обсуждают их, предлагают технические и архитектурные решения, описывают методику тестирования, какие-то передают в работу дизайнерам и программистам, по каким-то задачам ставят вопросы аналитикам и аналитики могут контролировать как идут работы по поставленным задачам.
Дизайнеры и программисты, заходя в свой слой видят, какие задачи стоят перед ними, какие приоритеты этих задач, обсуждают эти задачи, моделируют интерфейсы и код системы, готовят эскизы форм, алгоритмы и декомпозицию процедур и функций, уточняют тестовые примеры, ставят задачи по тестированию пользователям-тестировщикам, ставят задачи по администрированию администраторам, обсуждают и готовят систему помощи, техническую и пользовательскую документацию.
И так далее по всем ролям.
Изначально, представления не задаются жестко, и количество ролей не ограничено. Но, тем не менее, один пользователь, для смены представления системы должен сменить роль, например, аналитик, для описания технического решения должен перейти в слой проектирования. Для конкретного пользователя может существовать набор ролей. Кроме того пользователи деляться внутри роли по иерархии, например, руководитель группы проектирования назначает конкретные ветки заданий конкретным проектировщикам и только он может утверждать в разработку принятые проектные и архитектурные решения.
Представление же в слоях может быть разным. Но для конкретных ролей доступны разные представления и с различными правами доступа. Например, программисту представления текста кода доступно полностью, проектировщику для просмотра и коментирования, аналитику вообще не доступно. Для диаграмм анализа наоборот, аналитику полный доступ, проектировщику для просмотра и комментирования, для остальных - недоступно. И разумеется, система должна разрабатываться, дополняться, сопровождаться и использоваться своими собственными средствами, в духе лучших систем :)
ex-Alex
113 - 30.05.2002 - 18:48
См. http://www.kuban.ru/cgi-bin/forum/forum9.cgi?page=1&ask=47981
Там все постулаты :(
БТР
114 - 30.05.2002 - 19:06
(106) Насчет проводок будущим числом. ДА. Однозначно, проводки по СЧЕТАМ ПЛАНИРОВАНИЯ нужно делать текущим числом.
Проводка по плану
30-05-2002
Дт ОжидаемоеПоступлениеМатериалов:Гайка М4:2003/Май/Первая декада/5
Кт ПланЗакупок:Цех №12:2003/Май
200 кг, 560 рублей
Проводки по факту
5-05-2003
Дт МатериалыНаСкладе:Гайка М4:Цех №12
Кт ОжидаемоеПоступлениеМатериалов:Гайка М4:2003/Май/Первая декада/5
200 кг, 630 рублей
Дт 10.1:Гайка М4:Цех№12
Кт 60.1:ЗАО "Гайкокомплект"
200 кг, 630 рублей
БТР
115 - 30.05.2002 - 19:18
(106) Что касается времени. И что такого особенного необходимо в таких операциях для работы с временем?
Функция ВремяПредставление(Чсл) //Представляет время в виде строки
Часы=Чсл%3600;
Минуты=(Чсл-Часы*3600)%60;
Секунды=Чсл-Часы*3600-Минуты*60;
Возврат Строка(Часы,2)+":"+Строка(Минуты,2)+":"+Строка(Секунды,2);
КонецФункции
Функция ВремяДанные(Стр)//Представляет время для использования в структурах данных для правильной сортировки
Возврат Число(Лев(Стр,2))*3600+Число(Сред(Стр,3,2))*60+Число(Прав(Стр,2));
КонецФункции
-------------
Но, тем не менее, где реально так уж необходимо время? Есть такое понятие - регулярность информационного потока. Она равна наибольшему периоду актуализации данных. Я сильно сомневаюсь, что на первом же управленческом уровне (начальник подразделения) интересна регулярность менее чем 2 часа. На втором управленческом уровне (начальник цеха), регулярность уже не менее 12 часов. Рабочий вряд ли станет фиксировать свои действия в системе. Если система датчиками регистрирует работу рабочего, то вполне достаточно сохранять статистическую информацию с регулярностью минимум 2 часа.
Мне видится это именно так. Где я ошибаюсь?
БТР
116 - 30.05.2002 - 19:23
(115) Мда, функция конечно неправильная :) Впрочем, не в этом суть, меня легко поправят :)
Секунды=Чсл%60;
Минуты=Цел(Чсл/60)%60;
Часы=Цел(Чсл/3600);
(114) Двоеточия обозначают разделение между субконто. Наверное так будет понятнее:
Проводка по плану
30-05-2002
Дт ОжидаемоеПоступлениеМатериалов[Гайка М4][2003/Май/Первая декада/5]
Кт ПланЗакупок[Цех №12][2003/Май]
200 кг, 560 рублей
Проводки по факту
5-05-2003
Дт МатериалыНаСкладе[Гайка М4][Цех №12]
Кт ОжидаемоеПоступлениеМатериалов[Гайка М4][2003/Май/Первая декада/5]
200 кг, 630 рублей
Дт 10.1[Гайка М4][Цех№12]
Кт 60.1[ЗАО "Гайкокомплект"]
200 кг, 630 рублей
ДМ
117 - 30.05.2002 - 21:37
Между системами класса ERP и V7 пропасть. Заполнить ее, конечно, можно пытаться и вручную, но не думаю, что любителей совком котлованы рыть надолго хватит.
Слаба V7 прежде всего в продуманности основ. Жидка теор. база. Нельзя на такой фундамент ставить массивные системы. Я говорю не о слабой реализации клиент-сервера, а именно о концепциях структур данных и иерархии классов для больших учетных систем.
А путь развития понятен. Укрепить фундамент и выстроить систему понятий от Таблиц Данных до Контура Планирования.
И только потом...
Stiw
118 - 31.05.2002 - 09:09
2(116) Покажи мне готовое ERP решение на базе 1С, на работающем предприятии и я с тобой соглашусь. Всё остальное демагогия. Рассуждать конечно можно, но толку от этого мало. По поводу (114-116) что можно сделать в частности нельзя сделать в комплексе. Если бы были возможности, то их бы уже реализовали, а не ждали когда нам разъяснят как :)
Галимов
119 - 31.05.2002 - 09:34
Господа, действительно чего вы привязались ко времени?
Давно уже реализовано (1998 год) - храним в строке плюс функции Тест(), Сравнить(), Сложить(). Кину по запросу на мыло agalimov#mail.ru
--
Пока все это писал мысль посетила - слабость 1С именно в скорости обработки данных (не хочу вдаваться в подробности, но есть задачи которые на 1С я так и не смог сделать), но недостатки software правятся достоинствами hardware. Подождем Pentium 10?
БТР
120 - 31.05.2002 - 18:47
(117) Надо же как ты закрутил. Такое ощущение, что мы тут все пачками ERP-cистемы внедряем. Ты хоть одну внедрял? Я нет. И ждать, пока фирма 1С сделает для меня крепкий фундамент и систему понятий я не собираюсь. А ты можешь ждать этого самого "только потом..."
(118) С чего ты взял, что мне нужно твое согласие? Меня интересуют конкретные проблемы и конкретные требования. Я предпочитаю все-таки рассуждать, а не фыркать презрительно и ждать, пока мне что-то покажут. Я с самого детсва не верю в сказку про "если бы было можно, уже бы было сделано". Знаешь, дураком я себя не считаю, и уж если я и не заткну всякого крутого ерписта за пояс, то и сам там за поясом сидеть не собираюсь.
Да бог с ней с 1С. Просто для меня это практический инструмент, на который есть спрос и есть желание на нем реализовывать серьезные системы. Не создавайте себе кумира. ERP- это только одна из моделей, созданная, кстати, теоретиками. Будем считать себя дураками и ждать крутых профессоров? А профессора, они, знать с другой планеты, где управление ресурсами ведется уже тысячи лет?
Кондаков
121 - 01.06.2002 - 00:00
Фух ажно дух захватывает ;) Классно я себе ветку сохранил уже и дома и на работе. Такие баталии просто здорово. Тока бъетесь вы уже напрасно ;)
Сказано: Кесарю кесарево. И нефиг 1С внедрять в Лукойле для управления. Ну не для этого она сделана. Хотя если прижмет то сделать наверное можно. Что касается вообще ЕРП. Ну что вы правда к этому привязались. Прав ТоТ и БТР ну нет ЕРП программы. Есть только программы на которыех это проще решать. Кстати аксапта это или power builder это уже вопрос вкуса и гонорара. Например если денег будет ну очень много то можно и на асемблере все это забомбить. (ну ооооочень много). ЕРП это стиль жизни. Так же как и ГААП. Причем он или есть или его нет. В одной конторе заказы товара делают по строго заданной формуле и негде там нет исключений. А в другой любое решение принимается по принципу 3П (в смысле три) Пол палец потолок. Пускай мы купим столько а там фиг его знает.
На счет убогости языка 1с. Блин ну не туда ты камень кидаешь. в асме язык был куда более убогий однако делали ;)) И ОС писали ;)) Нефиг на зеркало пинять коли рожа крива. Что многое надо делать через нестандартные (мягко говоря) отверстия ;)) С этим мало кто поспорит. Но это так сказать расплата за быстрый способ разработки экономических решений не нравиться бери делфи или нет MSVC вот это просто жопа %) Язык до безумия класс все могет все умеет тока сделай там (ну не буду особо мучить) ну к примеру бухгалтерию ;)) А потом не забудь все это быстренько менять ;)) Что ну его нафиг вот и я так думаю ;))
Но ветка Рулез сорри если я чего не так сказал ;)) Не со зла я ;)
SO
122 - 01.06.2002 - 01:15
В последнее время, в кругах системных аналитиков стало очень модно бросаться страшными словами типа ЕРП, ЦРМ, МРП-2 и т.д. Вот только совдеповским руководителям глубоко наплевать на все это. Ну, подавляющее большинство топ-менеджмента средних предприятий не умеет и не желает учиться анализировать даже те данные, которые мы способны им предоставить стандартными средствами 1С без извращений. Нарисуй на своей торговле с расширенной аналитикой по контрагентам аббревиатуру ЦРМ, дай рекламу, и люди будут ставить. Думается, еще долго в нашей стране красивые слова останутся только словами, а реальная работа будет делаться в 1С(например).
NoName
123 - 01.06.2002 - 11:31
Проблемма не в том, на какой платформе писать блок задач ЕРП, а в том, что сейчас мало руководителей, способных оценить нужность этой самой ЕРП. Да и какая ЕРП поможет если нет понимания о нормальном документообороте. Пример: уже не раз обсуждалась проблемма, когда продают еще не оприходованный товар. Какой анализ складских запасов и планирование закупок после этого. Действительно, прав был профессор Преображенский, говоря о "разрухе в головах".
Jora
124 - 01.06.2002 - 15:00
2(123) "уже не раз обсуждалась проблемма, когда продают еще не оприходованный товар. Какой анализ складских запасов и планирование закупок после этого" - вот в подходе к этой, и подобным проблемам, и заключается разница между системами управления предприятием, и "бухгалтерскими" программами.
Вот и в данном случае - товар то как раз оприходован (он уже на складе), просто нет сопроводительных документов. Согласен, это непорядок (потому что у нас действует принцип "нет бумажки - ты букашка, есть бумажка - человек"). Но если мы управляем предприятием, мы все равно отпустим товар со склада в производство/продажу (и это понимает любой руководитель, даже как вы говорите с "разрухой в голове"). А вот если мы поставили систему, чтобы главбуху было легче проводки вводить да отчеты в фискальные органы представлять - тогда да, можно послать всех куда подальше - не положено и все тут. И будет опять завскладом записывать все это в тетрадку. Действительно, какой уж тут "анализ складских запасов и планирование закупок после этого".
Кондаков
125 - 01.06.2002 - 17:04
2(124) Блин да не надо всех этих извратов. Ну как ты мне объясни товар попал не склад без бумажки. А все очень просто кому то было лень поднять зад и забрать онную у водителя или передать в бухгалтерию. А вот если бы директор не принимал на склад без бумажки вот тогда бы не надо было извращаться и жалеть бедного буха. Порядок есть порядок. И он либо есть либо его нет! Это не мед (с) Вини пух ;)
В конце концов бумажки могут быть финансовыми и управленчискими. Последними можно оформлять все что хошь вплоть до выхода по нужде.
В этом и фишка!
Тот
126 - 01.06.2002 - 17:26
2(121) А почему на Лукойле 1С не следует внедрять? Потому что "не для того сделана" или потому что невозможно? А может потому что дешево получится? Мне, например, кажется, что Лукойлы попрще на порядок чем автозаводы какие... Это же холдинг. Мы прекрасно внедрили 1С на "Энергоатоме" в Украине. Очень довольны... С цифрами в миллирды долларов 1С прекрасно справляется... Мне кажется, что на Лукойле 1С - в самый раз...
2(АтатолийТ)
127 - 01.06.2002 - 17:58
>"Потому что "не для того сделана" или потому что невозможно"
Потому что неЦЕЛЕсообразно.
+
>"Мне, например, кажется..."
Кажется - перекрестись :) The devil is in the details
Кондаков
128 - 01.06.2002 - 18:01
2(127) Слушай свое неудовлетворенное самомнение можешь выражать где нить в туалете. Запарили все начало ветки с ТоТом спорили.
2(126) Тот. Это образное выражение. Я не знаю какой документооборот в лукойле и энергоатоме. Прежде всего ставить 1С или нет вопрос производительности. Если документооборот превышает 25000 в месяц наверное можно и поставить но писать надо вообще с нуля причем все с учетом скорости.
В Лукойле
129 - 01.06.2002 - 18:06
используется и 1С, и R3, так что успокойтесь.
Кондаков
130 - 01.06.2002 - 18:08
2(129) %)))) Спасибо ! ;)
2(129)
131 - 01.06.2002 - 18:22
Но нас устойчиво убеждают, что будет достаточно только одной 1С :)
Кондаков
132 - 01.06.2002 - 18:31
2(131) Я что то не заметил что бы здесь кого то в чем то убеждали. У вас батенька самомнение болезненное. не надо все на свой счет воспринимать. Тут люди вообще никого не убеждают а просто свое мнение высказывают. Не согласен отвечай конструктивно.
Кстати на счет того достаточно ли в Лукоиле 1С. В принципе можно солнце обос.... что б оно шипело. Вопрос в том насколько это будет изврат. Сколько на это уйдет времени. Что останется от 1С. И нафиг это надо если есть более приспособленные программы? Причем последний наверное самый главный. Как говорилось в 121 Кесарю кесарево. Ну не надо на делфи писать Boot loader, И на ASM никто не пишет Web - Portal. Так нафиг 1С насиловат. Не уж то сложно еще один язык выучить. Они же все как братья близнецы
2(132)
133 - 01.06.2002 - 18:53
Убеждают (см., например, в 126 "Мы прекрасно внедрили 1С на "Энергоатоме" в Украине. Очень довольны... С цифрами в миллирды долларов 1С прекрасно справляется..."). Давно (имелась в виду позиция ув.Тот'а, которую он неоднократно высказывал не только в этой ветке).
Все, пошел в туалет по совету в (128) :)))
DimonMMK
134 - 01.06.2002 - 19:05
Я, пожалуй, эту ветку сохраню, почитаю на досуге... уж больно длинная. И люди новые. Завтра вернусь.
Кондаков
135 - 01.06.2002 - 19:09
2(133) Не обижайтесь коли чего не так. Просто начало топика сплошь перебранка с ТоТом. Ну внедрили и хорошо! Довольны вообще замечательно. Здесь же ТЗ не приведено. Кто его знает чего там внедрено. А мож в этом Энергоатоме, мазохисты все а мож фирма ЛВТ делает невозможное. это все детали тем не менее вся ветка про возможность сделать ЕРП на 1С и тут уж (при всем уважении к ТоТу) основными лицами были БТР и mazzy причем мне почему то верится что все что сдесь приводилось прочувствовано на личном опыте. Не надо переходить на личности ;)
Тот
136 - 01.06.2002 - 19:13
2(128) В Энерогоатоме порядка 60 документов в день по бухгалтерии. Правда, это одноэсоских. А некоторые из них формируют сотню бумажных. Народ, я работаю с холдингами. Они и близко не валялись с супермаркетами по объемам.
Может (127) имеет другие данные? Так - в студию, как говорит Якубович. Кстати, на ГП Энергорынок, через который идут расчеты за вообще всю э/э в Украине, документов еще меньше. Наверняка меньше, чем в каком-нить ЖЭКе.
Мифы у вас в головах...
2(Тот)
137 - 01.06.2002 - 19:37
"...по бухгалтерии". Ну так и говори про "автоматизацию" бухгалтерий холдингов. Но управление ресурсами предприятия (ERP) тут-то при чем?
"...идут расчеты за вообще всю э/э" - это тоже понятно (типа мини-биллинговая система между несколькими десятками участников). Но, опять, управление ресурсами предприятия тут где валялось?
БТР
138 - 01.06.2002 - 20:05
По количеству документов.
Следует различать документы необходимые для принятия управленческих решений разных уровней и документы, необходимые для оформления отношений с внешними контрагентами.
Могу сказать однозначно, вполне нормально 1С выдерживает такой же оперативный документооборот, что и любая другая система.
Просто нужно очень четко развязывать конфликтующие потоки данных.
Например, процесс отгрузки со складов требует совсем немного информации оперативно. Текущие резервы и остатки, ожидаемые поступления, состояние расчетов с контрагентами, договорные условия.
Я очень даже легко представляю себе полностью замкнутую оперативную систему сбыта, на которой в 1С (!) будет работать хоть тысяча человек. Это только кажется сложным, если упираться в разные технические ограничения платформы 1С, ни одно из которых даже не придется преодолевать. Думаю, что если поставить такую задачу перед какждым из нас, все ее смогут решить. Подразумевается, что делается элементарная работа: регистрация договоров, выписка счетов, регистрация поступивших оплат, загрузка текущих цен и обновление ассортимента, формирование документов на отгрузку и запись аналитической информации по продажам и взаиморасчетов. Никаких аналитических отчетов. Резервирование товара прямо во время подбора в форме накладной. Остатки напрямую из регистра.
Это сложно? Думаю что нет.Как часто нужна информация из этого контура в других контурах? Назовите мне контур, кому это будет необходимо чаще чем один раз в день. Может быть я что-то упустил?
Дело в том, что количество оперативно-зависимых потоков данных (ОЗПД) на предприятии строго ограничено пропускной способностью обычной связью человек-телефон-человек. Поэтому, все основные ОЗПД чаще всего располагаются локально.
Вот на этом принципе и строится вся идеология оптимизации. НЕ ПРЕДОСТАВЛЯТЬ ИНФОРМАЦИЮ ЧАЩЕ, ЧЕМ ОНА РЕАЛЬНО НУЖНА. А на какой платформе будет реализовываться ИНТЕГРАЦИЯ значения не имеет. Другое дело, что сейчас у 1С нет готовых кубиков для такой интеграции. Лично я нацелен на разработку таких кубиков. Я очень осторожно отношусь к выбору платформы и знаю множество ограничений платформы 1С. Но, тем не менее, в своей архитектурной модели я пока не наткнулся на эти ограничения. Так что, ваши мысли по реальным проблемам и их причинам буду воспринимать с благодарностью.
Тот
139 - 01.06.2002 - 20:18
2(137) А какие у холдинга ресурсы? Плановый и договорной отделы тоже автоматизировали... Финансовую службу... Растолкуй темному - чего еще надо?
Мы ВСЕ в холдинге автоматизируем. Все, что ему надо... Даже канцелярию. Учет входящих-исходящих, контроль исполнения... Странный ты какой-то. Выучил умные слова - и употребляешь их налево-направо...
Кондаков
140 - 01.06.2002 - 23:53
Блин ТоТ чес слово мы тебе верим не надо утверждать что 1С всемогуща
Лично я все равно не поверю причем не потому что я упертый а больще потому что программист давно и не только в 1С и по этому представляю себе внутренние механихмы работы
Ну нельзя на недоделаной базе данных выполнять крупные расчеты с той же скоростью что и на оракле. Просто нельзя потому что не для этого она писалась И не надо говорить что у вас все получается я с этим и не спорю. И даже венрю а главное надеюсь что 1С можно внедрить где угодно. Суть не в этом у этой программы есть свое назначение все остальное изврат
Тот
141 - 02.06.2002 - 00:23
2(140) Да это не 1С. Это я всемогущий. 1С то при чем?
Насчет производительности - существует понятие комфортность. И множество мифов, что "1С не тянет". На одной из АЭС в в ОКСе пытались внедрить. Не потянула... 5 компьютеров... Так ихний АйТишник и сказал прямо на совещании... Не врубился, видать, что делегация только что вернулась из Киева, где видела 30 комфортно работающих в базе юзеров. Конфуз, в общем, получился...
Ну почему же все остальное изврат? R/3 нормально работает на IBM, Крайслере. Это не изврат. Только не за 2 лимона баксов. Гораздо больше...
Кстати, я предлагаю клиентам после внедрения 1С переписать все на Оракле, например... Пока желающих не нашлось...
GRN
142 - 02.06.2002 - 00:36
Тот от безделья что-ли тут треплется ?
Тот
143 - 02.06.2002 - 00:46
2(142) Точно. Если я тебя раздражаю - не ходи в эту ветку.
Для меня 1С - всего лишь инструмент экстремального программирования, позволяющий с минимальными затратами достичь нужного функционала системы.
А вы рассматриваете "тяжелые" системы как панацею. А то, что R/3 за 2 лимона - это отстой - слышал неоднократно от ее прежних пользователей... Приличную систему на базе R/3 можно построить, если в кармане хотя бы 20 лимонов...
А переписать функционал внедренной 1С-системы на другой инструментальной базе - все одно куда дешевле будет...
Тот
144 - 02.06.2002 - 00:49
http://www.m2system.ru/analit36.shtml
pit
145 - 02.06.2002 - 10:10
(143) - в словах "А переписать функционал внедренной 1С-системы на другой инструментальной базе - все одно куда дешевле будет..." - истинный смысл использования 1С при попытках постоения больших систем (ИМХО, под большими понимеется от 30-40 и выше в единой базе). Т.е. если заказчик грамотный и надо систему на достаточно большое кол-во пользователей с нормальным функционалом - он изначально на 1С не сядет. Если неграмотный - сядет на 1С и приобретет опыт. Начиная с некоторого уровня такая система будет затыкаться (захлебываться). НО - если опыт построения на 1С пойдет впрок, созданная на 1С система послужит моделью (и очень дешевой) для построения системы на другой базе - первоначальные условия уточнены и детализированы на 1С. Если же заказчик начинает орать об отстойности 1С - значит, мозгов не хватает и обобщать не умеет.
.
Не надо смешивать возможность построения таких систем на базе 1С и крайне кривую работу движка. Теоретически можно построить нормальную систему на 1С, практически из-за кривости реализации самого движка - цель недостижима. Точнее - система до определенного предела будет работать, затем захлебнется. Просто надо четко отдавать себе отчет в этом. И не кричать - 1С рулез или отстой. Определенная ниша заполняется 1С полностью, при приближении к границам по объему, скорости, кол-ву юзеров - вопросы типа КАК ускорить работу.....
.
в (138) приведено нормальное решение по ускорению работы в целом (решения продиктованы особенностями платформы). Граница за счет грамотности решений отодвинута значительно дальше. Ну и что?
.
При декомпозиции системы начинают возрастать ресурсы и затраты на обеспечение целостности и жизнедеятельности системы, при растут они нелинейно. Есть достаточно близкая граница и такого решения. Но опять таки НО - построение такой системы на базе 1С дает понимание того, что же все таки требуется, уточнены конкретные требования конкретной организации, проведена их детализация и ранжирование. И САМОЕ ГЛАВНОЕ - наведен какой то порядок и дисциплина. В этих условиях переход на любую другую систему классом выше пройдет гораздо быстрее, будет гораздо менее затратным и более быстрым. Возможно даже, в рамках новой системы на нижнем уровне будут применены отработанные решения на базе 1С. И тогда можно говорить не о 20 млн баксов, а о 2-х.
.
Так что в словах насчет моделирования - правда, причем это касается, наверное, любой системы, подошедшей к своему потолку.
Северянин
146 - 02.06.2002 - 12:06
Наблюдая за развернувшейся дискуссией, создалось впечатление, что практически Все правы. Просто не были заданы начальные условия:
1. Степень готовности топ менеджеров для внедрения Системы Управления Предприятием или как еще иногда расшифровывают КИС Комплексной Информационной Системы(А по большому счету ERP это и есть КИС). Т.е. готовность верхов
2. Степень подготовленности пользователей для внедрения подобной системы.
3. Степень готовности принятого на фирме документооборота для внедрения подобной системы.
Т.е. когда назрела революционная ситуация "верхи уже не могут управлять по старому, а низы еще не готовы работать но новому". В такой ситуации и находится большинство наших компаний. И вот тут то и появляются "шустрые" ребята которые говорят: "Давайте мы вам поставим ERP ситему и все будет ОК". А поскольку у многих топ менеджеров есть огромная надежда и иллюзия, что какая-то новомодная программа решит за них их же проблемы, то и вбухиваются огромные деньги в дорогостоящие проекты. И тут я полностью согласен с дискуссантами, которые в качесте начального уровня внедрения предлагают 1С. Просто нет более эффективного (не смотря на все недостатки) интрумента, который позволит в экстримальном режиме навести элементарный порядок и обучить пользователей современным методам управления. В отношении холдингов или понятия БОЛЬШИЕ, я полностью верю Тоту, что в Энергоатоме реализован весь необходимый функционал. Сам работал в холдинге, где объем ежемесячного документооборота сопоставим с недельным документо оборотом среднего супермаркета (а может и меньше). Так что размеры ни о чем не говорят.
Тот
147 - 02.06.2002 - 13:50
Северянину: Я не верю, что где-либо в мире есть предприятие, где весь персонал спит и видит себя в некоей ERP. И СНГ - не исключение. Другое дело, что у нас - даже в негосударственных конторах - достаточно высок уровень коррупции. И "блатники" во всех звеньях - обычное явление. А работа с серъезной системой требует серъезной переподготовки. Напряжения мозгов. И кому оно надо?
В целом с постингом абсолютно согласен. Кроме того, что обычно все же от "новомодной программы" ждут не чудес. А реальной монеты в кармане. Лично беседовал с людьми, которые мне это говорили прямым текстом. Типа "Вы нам мешаете. Ваша система слишкам дешева, чтобы быть интересной для нас. И мы не допустим ее на наше предприятие. Вот если бы вы смогли руководство убедить, что нам R/3 надо - тогда другое дело..."
Северянин
148 - 03.06.2002 - 08:13
Тоту. Я намерянно нарисовал полу-реалистическую картину. На самом деле все гораждо сложнее. Для чего необходим современный механизм управления Предприятием, включая управление русурсами, клиентами, прогнозирование и тд.? Прежде всего для получения конкурентных преимуществ на рынке. И пока в стране получение таких преимуществ не зависит от Системы управления предприятием, а зависит совсем от других приемов, востребованность в ERP и других подобных системах - просто мода. Нужно показать: какой я крутой и продвинутый, у меня даже стоит самая крутая система. А на самом деле реально работают совсем другие метоты управления. Конечно чем ближе предприятие находится к Госкормушке, тем больше денег вбухивают в ИС, прежде всего исходя из изложенного тобой примера.
Крокодил
149 - 03.06.2002 - 09:40
2(148) Вот замечательным пример такого предприятия, близкого к госкормушке, является контора - основной заказчик ТоТа. В нормальных условиях оно бы уже давно было банкротом - ТоТ, на какую сумму у них долгов?. Но при наличии личных связей и заинтересованности такую контору очень удобно автоматизировать - можно впендюрить что угодно - "и все довольны".
А весь треп г. Туровского про ЕРэПэ / МэРэПэ и ёксель/моксель нужен чтобы оправдать, почему за уплаченные 100 с лишним тысяч баксов контора получила слегка подправленные типовые от 1С. Жаль только путается под ногами местный отдел информатизации - а то бы Тот еще не так развернулся. И действительно - лохи - не понимают своего счастья.
Вот такая получается ERP. Ну не глупо ли спорить о таких высоких материях со старым, хитрым евреем, преследующим свой корыстный интерес?
ДМ
150 - 03.06.2002 - 09:47
2 БТР (120) Хм... Ну, во-первых, не сидим и не ждем. А во-вторых, именно потому, что несколько лет развиваем и внедряем собственную комплексную конфигурацию, сделали для себя кое-какие выводы.
Один из примеров "простоты" платформы V7. Тут где-то поминали бардак с мультивалютным учетом. Схожая проблема с учетом товара в разных единицах измерения. А фишка в том (IMHO, естественно), что, вообще говоря, ресурсы регистра должны храниться в отдельной таблице (таблицах), подчиненной основной. В основной таблице д. б. записаны значения детерминанта (набора измерений), а в подчиненной таблице ресурсов - ссылка на единицу измерения (подчиненный детерминант) и значение ресурса.
Количество таких "маленьких фишек" в V7 довольно велико. Каждая из них сама по себе не критична. Но в больших проектах становится критической их общая масса.
Stiw
151 - 03.06.2002 - 10:03
Сдается мне что данная ветка становится имиджевой рекламой для некоторых господ. Суть её сводится к всемогуществу конкретного индивидуума с 1С запазухой. То что они сами не ведают про проблемы которые им здесь объясняют, сумлеваюсь. Значит вешают нам целенаправленно, вопрос зачем?
Наверное заказчики форум читают, так вы для них виртуальный создайте и поддерживайте, а нам вешать не нужно.
Бука
152 - 03.06.2002 - 11:18
Господа! (высовываясь из окопа), так все-таки что-то реально можно сделать в рамках 1С или нет? Если можно, то какие ограничения накладываются на такие решения? (только ногами сильно не пинайте что влез в вашу дискуссию <здесьдолженбытьсмайлик>)
666
153 - 03.06.2002 - 13:04
2(152) - Можно, но с большими ограничениями - небольшое количество пользователей, функционал, соответствующий только данному предприятию. увеличение. Увеличение этих двух параметров приведет к неспособности 1С технологически справлятся со своими функциями.
БТР
154 - 03.06.2002 - 18:45
Реально сделать можно. При учете, что в одну конфигурацию не будет одномоментно вводиться более 500 документов в час. Это главное ограничение.
Остально очень и очено надуманно. Не стоит переносить в технические решения изобретения пользователей для своих нужд и тогда реализуемы все бизнес-процессы. Вы сначала опишите ВСЕ бизнес-процессы, а потом спорьте, нужно делать так как вам кажется, или можно сделать проще. Надоело уже спорить. Да, "маленьких фишек" много. Да, общая масса может быть критичной. Посмотрите на архитектуру других систем. Там есть столько же много маленьких фишек. Или вы думаете, что кто то очень умный в R3 придумал более быструю схему расчетов итогов по учетным регистрам?
Просто с умом нужно подходить к анализу. А не к "маленьким фишкам".
Вот вам моя аксиома. Постулат на который я опираюсь. Фишки требуются тогда, когда не понят смысл решаемой задачи. Когда понят смысл, задача решается на другом уровне на порядок меньшими средствами.
Да, бывают проблемы. 5% от общего объема кода. И эти 5% нужно оптимизировать. Хоть на ассемблере. Но только не надо гнать, что 95% остальных элементарных задач нельзя сделать в рамках 1С. И не надо гнать, что VC++ с OLE объектами работает быстрее/лучше/правильнее чем 1С.
Хватит уже упираться в бордюры на тротуаре. Ноги поднимаются таки немного выше.
БТР
155 - 03.06.2002 - 18:54
Блин, я уже зол. Это не смешно.
Вы что, всерьез считаете, что другие системы больше подходят для ERP?
КАКИЕ И ПОЧЕМУ? Забейте вы на технические проблемы, ей богу. 1С это открытая система. Здесь что, никто никогда не интегрировал несколько сторонних компонент на DELPHI или несколько объектов ActiveX на VC++? Что, там другие глюки, чем в 1С? Сколько нужно времени на разработку новой компоненты или нового объекта ActiveX? Какое соотношение по скорости разработки отчета или формы в 1С и Oracle Designer? Дайте мне столько же времени на проект и те же деньги, что даются на разработку систем в Oracle и получите изюминку работающую с такой же скоростью и надежностью, но более удобную и обслуживаемую. Меня достали уродские заявления о том, что надо подправить dll в CrystalReport или десяток вызовов WinAPI в компоненте, чтобы цифры на отчете попали в клеточки, а кнопка таки вызывала правильную диалоговую форму.
Достали уже, реально. Идите на другие системы и парьтесь, если считаете, что там меньше проблем. Простите, я ушел на 1С, потому что ЗДЕСЬ меньше. Я как то оценил время и бюджет проекта разработки компонент реализующих функциональность 1С в Delphi. Получилось 1.5 года и 180.000 долларов. Кому это надо? Проще разработать ускорялки и оптимизялки для 1С. И использовать их в 5% КОНКРЕТНЫХ СЛУЧАЕВ. Мыслите уж с точки зрения бизнесменов, если уж лезете в категорию систем класса ERP.
Достали.
ex-Alex
156 - 03.06.2002 - 19:00
C "быстрой схемой расчетов итогов по учетным регистрам" ты промахнулся - SQL запрос отработает на порядок быстрее 1С :)))
У меня есть знакомый, у которого на 2PII-450, 512 ОЗУ 150 юзверей на базе в 9 гигов (причем не одноэсовских, где 40% объема - служебные данные). Причем БЕЗ ХРАНЕНИЯ ПРОМЕЖУТОЧНЫХ итогов. Обычные SP и SQL запросы.
А про 500 документов в час - это словоблудие. Сделай макет - посмотрим.
Боюсь тема для тебя стала идеей фикс - лучше завязывать. А то в Тот-а превратишься. Только у него "энергетический холдинг" и "100 тысяч". Аж с 60 документами в день! А у тебя ERP будет.
БТР
157 - 03.06.2002 - 19:09
Елки-палки, неужели нужно объяснять очевидные вещи, что качество и скорость разработки и внедрения НЕ ЗАВИСЯТ от платформы более чем на 10%? 90% скорости и качества зависят от методики и дисциплины.
Если постоянно латать и латать программу, не имея ни общего актуального анализа, ни текущей и перспективной архитектуры, ни организационных рычагов воздействия на учетно-расчетную политику, ни полномочий влиять на реорганизацию бизнес-процессов, то на чем ни пиши, будет косо, криво, немасштабируемо и нетиражируемо?
ERP это не догма. Там нет полной интеграции. И нигде, никогда не будет полной универсальной интегрированной системы. Зато есть парадигма учета по бухгалтерским счетам. Есть парадигма организации учетного документооборота. Если эти две парадигмы последовательно внедряются на предприятии, если корпоративная культура основана на порождении точных регламентов, если хозяина интересует в первую очередь прозрачность и управляемость системы, то ВСЕ РАВНО, НА ЧЕМ ПИСАТЬ КИС. КИС имеет границы автоматизации, которые могут быть разными и могут изменяться с течением времени. Надо учиться планировать стратегию развития КИС и АИС. И учиться ее выполнять.
Я вообще пока не нашел АИС, которая меня бы полностью устраивала. Я уже описывал в этой ветки критерии, которые я считаю строго необходимыми для удачной АИС. И пока, считаю, что соотношение достоинств и недостатков в 1СV7 наилучшее для нашей страны. Причем на порядок относительно других систем.
БТР
158 - 03.06.2002 - 19:27
(156) На счет скорости, положим, ты прав. Но речь о том, что я считаю возможность прямых запросов к SQL я считаю НЕОТЪЕМЛЕМОЙ ВОЗМОЖНОСТЬ ПЛАТФОРМЫ 1С. При этом, НЕ НУЖНО МЕНЯТЬ СТРУКТУРУ ХРАНЕНИЯ УЧЕТНЫХ РЕГИСТРОВ. Но, в ОСОБЫХ СЛУЧАЯХ - можно. И нужно.
Для меня на данный момент в V7 есть только одна беда - отсутствует наследование объектов. Это здорово усложняет поддержку систем и нарушает нормализацию функциональной декомпозиции.
Все остальное - вполне решаемо. Единственное, что я бы еще хотел иметь - это возможность вести древовидные комментарии и управление версиями, что, вообще говоря, решается внешним редактором md или исползованием внешней компоненты Compound.
Меня больше всего раздражает угрюмая обреченность в отношении к платформе 1С. Поэтому я предлагаю попрограммировать на C++ или Delphi пару околоКИСовских продуктов, попариться альтернативой поиска и приклеивания через что-то чужих компонент или многонедельной разработкой собственных. А потом понять, что та же альтернатива есть и в 1С.
Больше всего меня раздражают мнения по поводу крутости xBase. ВСЕ ЧТО МОЖЕТ FOXPRO может и 1С. Никто не заставляет использовать стандартные объекты 1С, а-ля справочников, документов, журналов и т.д. Есть объект таблица значений, есть ADO DB, есть внешние компоненты для перехвата событий мыши и нажатий клавиш. Что еще такого есть в других системах? Берите и пишите.
Что такого есть в готовых кубиках от SAP, Navision, Oracle, Scala, BAAN? Берите и пишите.
Почему-то в программировании на 1С принято лениться и ругать типовые. Разумеется, потому что лениться и ругать кубики в Парусе, Галактике, Аксапте, Сапе, Скале, Оракл Аппликейшн или БААНе беспонтово. Там деньги платят за трудоемкое программирование. А в 1С, видимо, за нытье.
Ну вас. Лично я лучше буду рисовать свои типовые кубики. Дайте только срок. Я не прошу 30 лет, сколько было у SAP. Я не прошу 15 лет как это было у Baan. Мне даже не нужно 10 лет, как это было у Галактики. Мне достаточно 3-х. И точной информации по восьмерке от 1С. Хочется соблюсти преемственность.
А иронии не надо. Скучно. Профессионалам лучше думать о способах решения проблем, а не о возможных проблемах, препятствиях, ограничениях.
Конструктивные предложения таки есть? Или будем играть в ню-ню?
!
159 - 03.06.2002 - 19:27
Браво, Крокодайл! Вы просто мануальный хирург) не сколько самого Тота, сколько много, оказываться, у него больных мест)))
Тот, рекламмы многова-то... Вам не кажеться?
ИМХО, Ваш имидж в этом форуме и так "непоККБЕЛИМ" (с), что оправдываться нестоит.
Тот
160 - 03.06.2002 - 20:06
2(159) За имидж спасибо. Честно говоря - у меня нет ни нужды, ни потребности растопыривать здесь пальцы. На самом деле меня в подобных ветках интересует АРГУМЕНТАЦИЯ. Очень радостно, что никто против использования 1С (даже 7.7) на крупных предприятиях ничего конкретного привести не может. Значит я не ошибся стратегически.
А что касается Крокодайла - просто интересно, откуда он про Субос наковырял. Это же не лень было! А больше в его постингах ничего интересного.
Ну а на счет рекламы - просто я оригинал. Рекламирую 1С на форуме, ей же посвященном... Для куражу...
Sasa
161 - 03.06.2002 - 20:25
2(158) Мне непонятно - ты то чего кричишь??? Надо время - нате, берите! Чтобы тебе догнать САП - тебе нужно по пять модулей в год делать - ну раскажи что ты уже сделал за то время что работаешь в 1С???
Ты хоть сам свой вопрос уразумеваешь - тебе говорят "не сможешь построить девяти этажку с помощью совка и ведерка" ты говоришь "а что мне мешает"??? В таком случае для начала мешает отсутствие осознания масштабов проблемы - дальше все вопросы отпадают сами по себе, даже наобороот - даже себе начинают казаться довольно таки глупыми, детскими....
Sasa
162 - 03.06.2002 - 20:30
2(160) Это не ты ошибся стратегически - это Прайсы не ошиблись - это они милионы зашибают на SAPе, а не копейки побирают...
Тот
163 - 03.06.2002 - 20:51
2(162) Да мне просто никто не поручал SAPы продавать. Это - элита! А мы так... Догоняем и перегоним... Я ведь жлоб. Мне обидно, почему им платят, а мне - нет. Вот и борюсь с несправедливостью как умею...
ASG
164 - 03.06.2002 - 21:51
Кстати, недавно копал фармацевтический бизнес. Буржуйский филиал. Основное направление работы - собрать банкет, подпоить главврачей, дать взятку лечащему врачу - т.е. подмазать всех, кому мы доверяем, выбирая медпрепарат, которым лечимся. Особо веселит картина, когда дохтур предлагает таблетки, фирма-производитель которых указана у него на халате. С дешевым Ферейном после этого не связываются.
Прямая аналогия с Прайсами и прочими. И ничего, миллионы зарабатывают. Может, это и есть правильно? По крайней мере финансово успешно.
mikekk
165 - 03.06.2002 - 21:57
(121)(126)Читаю ветку с середины. На работе времени не было. В ЛукОйле кстати, по крайней мере в Волгограде и в наших филиалах используется программа на стареньком фоксе.
ДМ
166 - 03.06.2002 - 21:58
2 БТР. Мы ведь просто обмениваемся мнениями, isn't it? Стоит ли так расстраиваться из-за тех, кто меньше знает, хуже соображает и много ноет?
К тому же во многом Вы действительно правы. Без оптимизма нет прогресса.
Nomad
167 - 03.06.2002 - 23:34
2 (БТР)
Сорри, что так - через форум, но очень хотелось бы обменяться контактами.
Тема - финансовое планирование. Прелюдия - структура хранения финансовых показателей, альтернативная ФП и КФ.
БТР
168 - 04.06.2002 - 08:21
(167) см. подмыльник
(166) Хорошего пива должно быть много
(161) Не так страшен черт, как его малюют. Уж если приходится строить девятиэтажки, то почему бы не строить их хорошо? А насчет совочка и ведерка, прости - ты кажется ошибся с метафорой. Порядков так на восемь. Перепутал с masm'ом, бывает. А что я уже сделал, и что еще нет - не кажется ли тебе, что это дешевый трюк? Ты же не видел, чем я занимаюсь. :)
Да видел я твои творенья
169 - 04.06.2002 - 09:05
(168) Извини, что анонимно. Не хочу дискутировать по этому поводу здесь.
.
Здравое зерно есть и не одно и не два. Грамотно некоторые вещи решены. Но - !!! На мой взгляд, недостатки платформы все таки сказываются и весьма существенно. Из-за чего временами ты выпрыгиваешь из штанов (я просто констатирую, что выкрутасы и прибамбасы - отнимают много времени). Просто были бы в платформе некоторые вещи (отсутствие которых здесь, в частности, активно обсуждается) - ты ушел значительно дальше.
ex-Alex
170 - 04.06.2002 - 09:49
То DM. Куда нам до вас умных! Да и с соображалкой сложно. :)
Особенно если аргументы - "нет бога, кроме Аллаха" и "все вокруг тупые". Если не хватает аргументов - нужно обязательно обхамить оппонента. И при этом растопырить пальцы пошире. "Оптимизм как средство решения проблем блокировок в 1С" - это тема для дисертации.
Или ты можешь оспорить хоть один мой постинг?
И вообще - я с этой темой завязываю. Удачи.
mikekk
171 - 04.06.2002 - 10:03
На самом деле, по моему мнению можно проекты делать на чем угодно. Хоть на ассемблере, хоть на 1С, хоть на R/3. Все зависит от постановки задачи и от количества денег и времени, вложенное в решение проблемы. Я принимал участие в создании микро-ERP системы на 1С для небольшого кусочка большого предприятия. На ней работали, на ней отлаживали бизнес процессы. И счас это переносится в САП. Как переносится не знаю. САП не смотрел. Но на 1С вполне можно сделать что угодно. Даже корову. И заставить давать её молоко. А по поводу быстродействия..... Для 1С в лучшем случае ставится 4-х процесорный сервер на ксенонах и то я только один раз видел подобную штуку. В САПе применяются как минимум SUN-ы, как максимум Dec-и ,IBM - ы, CRAY-и и пр. Просьбва ИВМ не путать с персоналками. Такие компьютеры стоют от 500 т$. И до бесконечности. Ставится оптоволокно. Попробуй поставить туда мс-сюл если станет и будет использовать все возможности машины-))....
 Большие системы применяются как правило по трем причинам: Откат, Возможность построить персонал (если получится) и показать (в первую очередь на Запад) что мы работаем по европейским стандартам. По ISO 9001. Давайте нам кредиты, покупайте наши акции, работайте с нами на равных и т. д. А в остальном - та - же самая программа. Написаная теми-же самыми людьми. Со своими ошибками и глюками. Так что если БТР чего-нибудь сваяет на 1С это будет прикольно. Но хохма еще заключается в том, что ЕРП системы не бывают универсальными. Каждая система настраивается на определенное предприятие и для другого эту систему прийдется перенастраивать заново. Причем прилично. Так что удачи. Может из тебя вырастет новый БИЛЛ-))) А вообще-то весь прогресс движется вот таким сумашедшим народом (в хорошем смысле этого слова). Будут идеи свисти-)))))))
NoName
172 - 04.06.2002 - 10:21
Мне кажется, если даже у БТР'а и не получится универсальная ERP - система на 1С, то у него появится методика написания подобных систем. А это иногда важнее чем сама программа. Удачи ему.
ДМ
173 - 04.06.2002 - 10:56
to ex-Alex (170). Торопитесь с выводами. Никто Вас не оценивал.
Перечитайте мои постинги. В 166 "мало знающие, слабо соображающие и т.д." относилось прежде всего ко мне.
Sasa
174 - 04.06.2002 - 12:41
2(171) "Я САП не смотрел - но я Вам раскажу что такое САП" :) А философы плодятся....
Тот
175 - 04.06.2002 - 13:15
2(172) Вот тут я согласен. Сделать тиражную систему гораздо сдожней, чем заказную. Поэтому возникают вопросы:
1) Насколько заказная система на 1С дороже других тиражных
2) Насколько время внедрения заказной на 1С больше, чем других тиражных
Если ответом будет "не дороже" и "не больше"
3) Зачем нужна "типовая" система? Кроме как для примера.
Путь 1С на корпоративный рынок - не через "типовые решения", а через специализирующиеся на отраслях (решениях) фирмы.
Nomad
176 - 04.06.2002 - 14:13
2 (175)
"Путь 1С на корпоративный рынок - не через "типовые решения", а через специализирующиеся на отраслях (решениях) фирмы."
IMHO, путь таки лежит через накопление знаний (опыта) и формализацию оных в форме методик, технологий, готовых элементов. Так вот пока в среде 1С всерьез этим почти никто не занимается - как инсайдер могу сказать даже за пару серьезных суперфранчайзи, создающих брандовые типовые отраслевые решения.
mikekk
177 - 04.06.2002 - 16:05
(174) А я никому про сап и не рассказываю. Я рассказывал про 1С... И асемблер. Если ты заметил.....
Sasa
178 - 05.06.2002 - 10:52
Тогда что придает тебе уверенности что в 1С можно сваять все что есть в R/3? Ты же не знаешь что уже есть в R/3...
Как можно поигравшись в песочнице на макетах, уверовать что этим же песочком и савочком сможешь построить девятиэтажный дом?:)) Ну только если этот девятиэтажный дом никогда сам не видел ...
Северянин
179 - 05.06.2002 - 11:02
2(178) Sasa ну что тебя так тянет в девятиэтажку? Дома бывают разных этажей но у всех практически одна технология (последовательность) строительства:
1. Предпроектное обследование (выбор площадки, определение, что же нужно Заказчику )
2. Проект (определение, как и из чего будем строить)
3. Расчистка площадки.
4. Закладка фундамента
5. Возведение стен.
6. Внешняя и внутренняя отделка
По этому речь идет не о том во сколько этажей построим дом, а о том как правильно строить.
БТР
180 - 05.06.2002 - 11:13
(179) Согласен. Самое главное - умение строить от начала до конца. А самое главное в этой области - методика, обеспечивающая ОБОСНОВАННОСТЬ принимаемых проектных и методических решений.
(178) Мне придает уверенность то, что все обратные утверждения НЕОБОСНОВАНЫ. Нет четкой логической последовательности от требований к сисетемам класса ERP к техническим ограничениям платформы 1CV7
Спасибо всем поддержавшим за поддержку. Спасибо всем критикующим за то, что не даете погаснуть огню энтузиазма :)
Alex_U
181 - 05.06.2002 - 11:27
(БТР) Я читал то, что ты написал в (62) и завидовал по-хорошему!
Как ты собрал столько знаний?
Не поделишься источниками (в инете или может быть, книжки хорошие порекомендуешь?)
Тот
182 - 05.06.2002 - 11:33
2(174) А почему ты считаешь, что я SAP не смотрел? Смотрел. Но ничего особенного там просто не увидел. Система как система...
2(176) Ты не туда смотришь. Посмотри, например, на Неосистемы Северо-запад.
А суперфранчайзи, торгующие типовыми поделками - это все же другое.
Если хочешь - еще несколько фирм назову.
mikekk
183 - 05.06.2002 - 11:54
(179)(180) Согласен целиком и полностью. (178) Ты знаешь, это мне напоминает разговор двух ламеров, начитавшихся на ихвт обзоров железа. Акорп-отстой, а вот асус-рулёз. Когда начинаешь спрашивать, кричат, что асус на целых пять процентов быстрее работает. А стоит дороже на 50%. Да я за эти деньги куплю проц на 30% работающий быстрее. Оракл круче МС-скюэль. Но только под определенные задачи. А в некоторых случаях МС-скюэль обгоняет тот-же оракл. Так что про то что R/3 круче 1С кричать не надо. Но под определенные задачи. Написана она на том-же с, работает на тех-же компьютерах, и настраивается и обслуживается теми-же людми. Одно могу сказать однозначно. Счас те люди, которые у нас настраивают сап обкатывали эти процессы на 1С. И продолжают работать в 1С. Они не програмисты. Исполнители. И немного постановщики задач. По крайней мере описатели бизнес-процессов. И они говорят, что некоторые вещи в 1С гораздо удобнее. Да что там говорить, я счас в 1С делаю один проект связаный с производством. Для обкатки. Сделал. На мой взгляд получилось логично и красиво. Люди, которые делает его-же в сапе, не может сделать то-же самое. Ей приходится вводить какие-то виртуальные склады, какие-то левые перемещения и т.д. Оно конечно работает. Но на мой взгляд не очень удобно. А некоторые вещи там получаются наоборот лучше. Я- ж говорю, что я толком в сап не лазил. Все впечатления от людей, с которыми приходится работать. Но то что он тормозит на 50 пользователях и SUN-не круче, чем 1С на 2хP3 и терминале мне говорил не один человек. Так что все зависит больше не от платформы, а от постановки задачи, правильного описания бизнес-процессов и их реализации. А на чем ты это будешь делать дело десятое. Самое главное соотношение Цена/Качество. И мне кажется это соотношение не в пользу R/3.
!
184 - 05.06.2002 - 12:03
Тот, а Вы всё не угомонитесь никак...аж ветка трещит
не пойму что Вы и кому пытаетесь доказать? что Вы делаете отличный подукт? от которого отличный?
Форум сделал из Вас бренд...скоро на этикетках пивных бутылок (лимонада и прочее) станут писать: тестировано Тотом...:)))
Sasa
185 - 05.06.2002 - 12:13
2(183)Ну насчет того что MS-SQL обгоняет ORACLE - это тоже к той же теме разговора двух ламеров - уж больно ты рекламы начитался:)
Какое нафик производство на 50 пользователей????????? Ты мне опять про песочницу - у вас что носки шьют???? Да такой объем спокойняк и на экселе вести можно:)
TO mikekk
186 - 05.06.2002 - 13:58
Слушай, а посмотреть не дашь? Что наваял по производству?
БТР
187 - 05.06.2002 - 14:03
(185) Прости, можно один конкретный вопрос? Ты можешь мне назвать систему, где в одной оперативной базе данных по производству необходима интенсивная работа более чем 20 человек? Я, вроде бы, думал, что не в песочницах копаюсь, а тут вон как выходит?
Например, сейчас у меня 12 относительно независимых филиалов, плюс центральная дирекция. На 10 филиалах пользователей системы 8-12, еще на двух 15-18, в центральной дирекции - 15-20. Пользователей, оперативно вводящих данные и требующие оперативной информации с регулярностью менее 10 минут во всем объединении всего 10-12 человек. Это в производстве.
До этого я работал в холдинге, там было порядка 50 пользователей системы, из них, пользователей, которым нужна была регулярность менее 10 минут было около 10. Это было производство, местная и региональная торговля через свои фирменные магазины, собственных менеджеров, агентов и представителей.
Перед тем я работал в холдинге, там было около 20 раздельных баз данных, в каждой среднем по 15 пользователей. Из них лишь по 3-4 человека на базу нуждались в регулярности данных менее 10 минут. Необходимая регулярность данных между базами вообще была больше одной недели.
До этого я работал на совместном с немцами производственном предприятии. Там было 25 пользователей, из них 8 пользователей нуждались в регулярности менее 10 минут.
До того я работал на крупном военно-промышленном предприятии. Там, правда, система делалась не на 1С (просто 7.5 тогда еще не было), а на Delphi 2.0 + MS SQL 6.5, но, тем не менее, в системе на 250 пользователей было только четыре группы по 5-6 человек, которым независимо друг от друга требоваласть оперативная информация с регулярностью менее получаса.
Знаешь, какой вывод я сделал? Чем крупнее предприятие, тем меньше оперативно зависимых групп пользователей на нем и тем компактнее оперативно-зависимые пользователи в группах.
Но, видимо это все были песочницы... Вопрос только, по сравнению с чем? И много ли у нас монстров, которые гораздо сложнее этих песочниц? Насколько, лично для меня, имеет смысл бросать накопленный опыт в разработке и внедрении систем на 1С и бросаться новичком в новую крутую систему для таких грандиозных замков из песка, что 1С в них просто не потянет?
VTools
188 - 05.06.2002 - 14:07
Мои 5 копеек:
1.От 1С вы некуда не уйдете.
Стремление 1С поглотить все ниши рынки обернулось плохим имиджем в средней и большой весовой категории. Но это вопрос времени, ибо тенденции налицо, как в самой фирме 1С (улучшение качества типовых конфигураций), так и в отношении к ней профессионалов (не только программистов, но и продвинутых бухгалтеров, аудиторов, менеджеров).
2.Набор объектов в 1С.
Пока функционала 1С недостаточно для того чтобы реализовывать большие проекты, но ничего не мешает этот функционал нарастить самим, тем более если позволяет бюджет проекта. 1С принесла в массы идею о наборе примитивных объектов, таких как справочник, документ, регистр, журнал, счет и прочее. Поэтому легко можно создать похожие объекты, но работающих с большими базами данных, например таких как DB2 фирмы IBM. Для этого надо дописать всего лишь 5% функционала 1С. Собственно, можно ничего не переписывать и работать напрямую с таблицами баз данных, но боюсь что внедренцу, которой по квалификации есть что-то среднее между бухгалтером и кодером, будет сложновато держать в памяти десятки связей между таблицами лишь для того чтобы запрограммировать простейший отчет.
Мало объектов - давайте создадим новые, нужен специальный объект - компонента, например, оптимальный расчет последовательностей через недетерминированные алгоритмы? Пожалуйста, сделаем. Не нравится точка актуальности или придумали новый "мягкий" алгоритм границы последовательности (вдруг решили, что не зачем перепроводить все документы, если изменился фактор, влияющий только на несколько документов)? Хочется создать регистр, где измерения хранятся отдельно от ресурсов? Почему бы и нет? Разве нет успешных примеров (хотя бы www.vtools.ru)?
Тот
189 - 05.06.2002 - 14:12
2(184) То что форум из меня бренд сделал - это его проблемы. Меня он интересует всего лишь как место подобных дискуссий. Для оттачивания мастерства пудренья мозгов клиентам.
А вот по поводу типовыых и заказных решений - могу сказать следующее: Мы были на семинаре фирмы Инталев в Киеве. Скажу сразу - фирму эту я очень уважаю. Посмотрели на их решение по планированию. По сравнению с тем, что мы делаем - .... НО! У них оно по теории. И действительно типовое. А у нас - заказное. Наше будет работать только там, для кого сделано. SAP, кстати, тоже отстой по сравнению с нашим. В типовом варианте.... Народ - ЭТО ДВА РАЗНЫХ РЫНКА. Типовые решения и заказные. Спорить надо не о том, что лучше, а о том, насколько типовое решение поднимает клиента. Насколько методики, заложенные в типовых, могут быть восприняты клиентом и какая ему от этого будет польза. А вот все, что SAP делает - на спор - в 1С повторю!
ppson
190 - 05.06.2002 - 14:17
189 - хотелось бы верить. но наверняка с огромным ограниченим - один потратишь лет 10 (так как в 1С нет удобных средств для создания больших систем) и система будет работать только с 5-10 пользователями (так как объем функционала подразумевает большой алгоритм проведения документов, то есть большое время на транзакцию).
mikekk
191 - 05.06.2002 - 14:17
(186) У нас производство виртуальное и весьма спецфичное. По крайней мере в моём блоке. + отгрузка. Так что ничего интересного там нет.
(185) С тобой похоже разговаривать безполезно. Я тебе про Ивана ты мне про барана. Специально для тебя повторяю.
Оракл круче МС-скюэль. Но только под определенные задачи. А в некоторых случаях МС-скюэль обгоняет тот-же оракл.
Речь не о том, что круче и быстрее. А о том, что можно-ли на этой платформе сделать определенную вещь или нет. И сколько это будет стоить. Соотношение Цена/Качество. ПОНИМАЕШЬ????
Сап у нас только настраивают. Поэтому и 50 пользователей. 1С-ов несколько. Достаточно много. И работают сами по себе в разных блоках. + Обмен информацией.
НО РЕЧЬ ТО НЕ О ТОМ. А О ТОМ, МОЖНО-ЛИ СДЕЛАТЬ НА 1С ЕРП-СИСТЕМУ. Я считаю что 1С в целом ничем не хуже других языков програмирования. Где- то лучше, где-то хуже. И на ней такую систему сделать можно. К тому-же что я видел в сапе на меня и на тех людей, которые с ним работают особого впечатления не произвел. Сап как сап. Свои плюсы, свои минусы.
ppson
192 - 05.06.2002 - 14:28
191) - согласен, можно. Можно и зайца научит курить. Но! эти системы должны управлять (помогать управлять) предприятием, то есть их должны использовать пользователи. а на система маштаба предприятия много пользователей. теперь представь что у тебя 1000 пользователей онлайн. Что ты придумаешь что бы система, написанная на 1С заработала?
mikekk
193 - 05.06.2002 - 14:29
Тот абсолютно прав. Только спор должен быть на достаточно приличную сумму. Потому как работы действительно прилично. И кстати, типовые конфигурации по сапу никому нафиг не нужны. Их все дорабатывают. А если их дорабатывают, то может проще с нуля написать????? (189) 5-10 пользователей????? А если сервак поставить, как в R/3???? Хотя-бы за 500000$$$$
mikekk
194 - 05.06.2002 - 14:39
(192) Да что угодно. Распределенка. Терминалы, СКЮЭЛИ, более мощные сервера. Доработка ДЛЛ-ей. Почитай (187)(188) Ребята дело говорят. У нас ведь как считается. Двухпроцессорный сервак с 2 гигами памяти это круто. А под НТ-2000 и восьми процессорный работать может. (Больше не знаю. Может и больше процов.) Может и на DEC-и, SUN-ы и IBM-ы, CRAY-и перейти. (Это правда шутка. Но в каждой шутке есть доля шутки) А на R/3 Нужна машинка гораздо дороже. Обеспечь для 1С то что требуется для сапа и тогда можно будет поговорить что медленнее и что быстрее.
ppson
195 - 05.06.2002 - 14:50
194) - у этих методов много недостатков или они уже выходят за пределы платформы 1С (dll писать и так далее)
распределенка - получение информации с большим интервалом времени, настройка синхронизация и т.д.
и к вопросу о запросах ERP систем - они не такие высокие как кажется. Все примерно такого же порядка.

196 - 05.06.2002 - 14:57
192 - а зачем 100 пользователей должны рабоать онлайн в ОДНОЙ 1с ?
Любое действие каждого должно получить одобрение остальных 99 ? нет ?
тогда пусть работают (4-9+начальник)*18 и еще 20 - смотрят место, куда это все сливается.
Убедил меня БТР.
ppson
197 - 05.06.2002 - 15:02
196) - потому что предприятия бывают разные.
mikekk
198 - 05.06.2002 - 15:04
(195) Да ну. Если у тебя будет 1000 пользователей то R/3 потянет какой-нибудь сервачек на PC???? Нет конечно. А распределенку настрой, что-бы загрузка-выгрузка происходила два раза в день на автомате. В 99% случаев большая оперативность и не нужна. Народ на складах не будет успевать документы вбивать. А самое главное в ЕРП-системах, что кстати никто не упомянул - ЭТО ПОСТРОИТЬ ИСПОЛНИТЕЛЯ. Что-бы он зараза вбивал все что надо. И если у него что-то не идет то искал свои ошибки а не орал, что програма не работает. А с этим уже сложнее. Может поэтому и покупают R/3??? Типа система западная. ISO-9000. Она неправильно считать не может. Мол, сакми дураки??:))))))))
Северянин
199 - 05.06.2002 - 15:10
(192) Ну представил себе "1000 пользователей онлайн..." и что как между ними разделены функции? Всем ли нужна оперативная информация? Речь идет о Системе управления ресурсами предприятия. Ресурсы могут быть Материальные, Финансовые и Трудовые. Степень оперативности изменения этих ресурсов разная. Отсюда и неоходимость в отслеживании изменения разная. На предприятии есть несколько уровней управления по которым потребность в отображении изменения резурсов тоже разная. По мимо этого есть такое понятие как планирование и прогнозирование ресурсов и тд. Если мы хотим создать систему класса ЕРП на полностью автоматическом производстве, с минимальным запасом ТМЦ и необходимотью отслеживать поставки с колес - одни требования к "скорострельности" системы. Если речь идет о нормальном предприятии с дискретным или непрерывном производством, то здесь начинают влиять факторы типа производства : серийное, мелкосерийное, экпериментальное и тд. И у всех будут разные требования к скорострельности. Но всем нужна нормальная система обеспечивающая конкурентные преимущества на выбранном секторе рынка. А отсюда в тебовании цена/производительность на первое место всегда ставится цена. То что ЕРП систему можно реализовать на 1С, по моему уже ни у кого не вызывает сомнения. А все остальное всегда зависит от конкретных условий. Я знаю одну очень большую фирму, которая то года три "крутила роман с САПом", то с Аксаптой, а в некоторых филиалах вообще не было компьютеров. О какой оперативности информации могла идти речь!
mikekk
200 - 05.06.2002 - 15:11
Ну не настолько и разные. Суть - то одна. Кто-то что-то производит, кто-то что-то продает. Не будет народ успевать из цеха какую-то бумажку вбить и где твоя оперативность????? А так и бывает. А надо кому-то посмотреть срочно кусочек в подчиненой базе, пусти его туда терминалом. Систему правильно построить надо. И все будет работать.
ppson
201 - 05.06.2002 - 15:12
198) Почитай дискурсию про Инталев+Комплексная, там как раз вопрос стоял о быстродействии. свелось к тому что кодеры дураки. на самом деле ограничение системы очевидны. Функционал можно написать на чем угодно, даже на бейсике для синклера. вопрос в том, сможет ли система с интретирующем языком быстро работать или ей надо подставлять подпорки в виде дополнительных dll, терминалов и т.д.
+ 1с не использует возможности MSSQL и это в третьем тысячелетии?
mikekk
202 - 05.06.2002 - 15:35
(201) Использует. Правда ты прав. Далеко не все. Но ты уверен, что АБАБ использует все возможности Оракла????? Дискусию про Инталева я немного посмотрел. Мне она не интересна. Но могу тебе сказать, что я принимал участие в разработке полностью самописной конфы, где используется бюджетирование. И там поначалу многие идеи брались у Инталева-2000. Счас там 40-50 юзверей. 2 терминала 2хП3+ скюэль2хП3, рэйд 5, серверворк. И ты знаешь, хотя летать не летает, но работать можно весьма конфортно. И если поставить третий терминал, юзверей 80-100 она потянет. Инталев+Комплексная - это универсал. Любая ЕРП-система-штучная вешь. А штучные вещи можно оптимизировать даже кодом 1С не залазия в Длл-и.
vs
203 - 05.06.2002 - 15:54
прикольно :)
http://www.axforum.ru/forums/showthread.php?s=e6dfbc7944dc0db1f5a62c715c784045&postid=2309#post2309
Stiw
204 - 05.06.2002 - 16:29
2(203) Эта ветка ещё одно подтверждение что у каждой системы есть своё предназначение.
Sasa
205 - 06.06.2002 - 09:50
2(191) Да потому что ты даже не понимаешь что такое транзакции, блокировки - как это реализовано все это в 1С. Курсы по языку SQL проходил - ах нет, ты и так все знаешь... ну ладно.
2(187) Вот для таких наколенных систем - их главная задача - это заменить EXCEL. У тебя что зарплата считается на основании данных из производства, у тебя что основных средств 40тысяч? У тебя ведется учет спецодежды - с ее офигенной номенклатурой? У тебя ведется на основании данных из производства учет износа оборудования? У тебя что есть планирование и распределение по местам возникновении затрат, у тебя что есть прогнозирование? Неужели твоя система хоть чем нибудь управляет? Далеко ли ты оторвался от уровня калькулятора? Нет врядли...
БТР
206 - 06.06.2002 - 10:16
По поводу производительности. Цитата из http://www.axforum.ru/forums/showthread.php?s=d19b0716ae155d231ed0588bc8bb881f&threadid=754
---------------------------------------
 Проблемы с производительностью системы
Странно, что на данном форуме до сих пор
не поднимался, как я считаю, один из важнейших вопросов
при эксплуатации системы такого уровня на крупном предприятии -
это вопрос производительности системы, т.е. сколько она может
тянуть одновременно пользователей и как быстро обрабатывать
их операции.
Например, у нас при одновременной активной работе 150-ти
пользователей, система виснет (MS SQL загружается на 100%
и появляются "мертвые" блокировки). И это при трех аосах с 4x700 ксеонами.
Поэтому, хотелось бы усышать мнение, по двум вопросам:
- Какой на ваш взгляд предельный уровень производительности системы (сколько она может тянуть пользователей при данной конфигурации)?
- И в чем на ваш взгляд основное слабое звено системы когда
во главу угла ставится производительность?
--------------------------------------------------------------------
Для тех, кто не в курсе: AOS - это Applications Operating System, по нашему - специализированная TSE.
(205) Обидеть надумал? Напрасно. Зачем выдумываешь, чего не знаешь. И зарплату считал на основании данных из производства (БАРП, СП Диприз), и основных средств было 470000 единиц, из которых было около 15000 количественные (Управление дорожным хозяйством), а уж учет спецодежды - перестань. Он у меня еще на Клиппере работал для заводов по 15000 работающих (например, завод стройдеталей,три бухгалтера и пять кладовщиков знать не знали слова производительность, все свистит). Что там сложного в спецодежде? И износ обороудования по выпуску, ты уж прости, что там сложного? Там что, нужно ОПЕРАТИВНО его начислять? Вот уж глупо ты себя выставил. Впрочем, даже тот самый ИТРП позволяет и зарплату, и износ, и прочие затраты на основании данных из производства начислять.
Что касается планирования и план-факта по местам возникновения затрат - ты знаешь другой способ? ТОЛЬКО ТАК планирование и делается и ничего сложного в этом нет. ДАЖЕ В ЭКСЕЛЕ.
А вот насчет управления - нет. Мои системы ничем не управляют. Технологическими задачами я не занимаюсь. И сомневаюсь, более чем критически, что этим занимаются ERP системы, а тем более универсальные. Не может одна и та же программа и ректификационной колонной управлять, и водку разливать, и пиво варить.
Кажись ты все-таки перестарался. Сбавь обороты. Давай лучше сначала пива выпьем, а потом будешь обсуждать объемы моих проектов.
Я не говорю, что я ВНЕДРЯЛ или ВНЕДРИЛ где-нибудь систему класса ERP. Я говорю лишь о том, что на данный момент не вижу для этого непреодолимых препятствий в платформе 1С.
Веди себя коректнее, плиз.
VVS
207 - 06.06.2002 - 10:21
(205)Интересно, а SAP (или что-нибудь подобное) где-то на ex-USSR это делают? Или только могут?
ppson
208 - 06.06.2002 - 10:29
(206) Хочу напомнить что кроме кривых систем есть еще люди с кривыми руками.
Приведу тебе еще один пример ERP: 2xXeon 700 1024 mb Oracle + AS + 150 тонких клиентов. Идет одновременный ввод накладных (приход-расход) + финансовое и физическое закрытие складов + формирование финансового результата + расчет зарплаты на 5 тыс.чел. Для пользователей это незаметно. Теперь представь что у тебя это все реализовано в 1С.
Закрытие склада - около 60.000 проводок (примерно час - два), финансовый результат - 70.000 проводок (2-3 часа) и примерно часа расчет зарплаты в 1С одновременно сделать невозможно, только последовательно, и при этом ты должен выгнать пользователей, так как все это будет делаться тремя длительными транзакциями, или надо проводить все это ночью. А если тебе необходимо и ночью что бы пользователи работали?
mikekk
209 - 06.06.2002 - 11:26
(205) Да, мы люди маленькие, скромненькие, курсики по скюэлю не проходили. А что там на курсах то интересного????? SQL за три часа и Вы компьютерный гений???? А извини за нескромный вопрос, ты на чем системы пишешь??? И какие проекты делал?????
БТР
210 - 06.06.2002 - 13:42
(208) Прости, не врубаюсь, что значит закрытие склада? Что значит финансовый результат? Что значит расчет зарплаты на 5 тысяч человек?
Очень интересно.
И еще, это ты говоришь об одном сервере, да?
ppson
211 - 06.06.2002 - 14:01
Закрытие склада - формирование остатков на конец отч.периода по соотвт. методикам (ФИФО, ЛИФО, средняя, ЛИФО на дату и т.д.)
Финансовый результат - Закрытие 2*, 3* (если есть), 4*, 9* счетов.
Расчет зарплаты - если не знаешь что такое расчет зарплаты на 5000 чел - сходи в расчетный отдел к расчетчикам, они тебе объяснять что это такое.
И все на одном сервере
БТР
212 - 06.06.2002 - 14:12
(211) :) Ох уж мне эти сказочники :))))
А что, у вас остатки оперативно не формируются? Прости, но в 1С НЕ НУЖНО делать закрытие складских остатков
Что касается финансового результата и 70000 проводок - спорим, из этого финансового результата анализируется ноль целых хрен десятых процента информации?
И что касается расчета зарплаты на 5000 человек, прости, вы его делаете каждый день и на все 5000 человек? У меня была зарплата на 15000 человек, да еще и на бейсике написанная. Самый долгий расчет бригадных нарядов выполнялся около 3 часов на старенькой-престаренькой 386DX40. С расчетами по шифрам затрат. И, прости, с чего ты решил, что это нужно считать на сервере?
Короче, сдается мне, что ты из мухи делаешь слона. Или я не прав?
ppson
213 - 06.06.2002 - 14:26
(212) могу спорить по всему кругу вопросов, только не на пустом месте.
Но боюсь что вы автоматизируете совок, в котором анализируется 0.0001% от всей информации и плановый отдел умер еще при советской власти.
Остатки нигде не формируются оперативном, если у тебя только не один склад, на котором у тебя храниться одно ТМЦ. и остатки никогда не будут формироваться оперативно и достоверно по методикам (ФИФО, ЛИФО) так как документы вводяться (и будут вводиться) в произвольной последовательности. постоянно восстанавливать эту воследоватьность в 1С - все знают какой это гемор.
Зарплата то считается, но уверен на 99.9% что когда у тебя 5000 человек, и разплата считается на 1С, то ты её ставишь отдельно, а не в едином комлексе с другими модулями (производством, финансовым и т.д.), так как расчет будет блокировать любые транзакции на пару часов. Вот тебе и технические достоинства 1С.
-----------------------------------------------------------
Подвел черту: ухожу из сабджа.
поверю в техническое могущество 1С когда увижу ИТРП+Инталев+Зарплата работающей единым комплексом (а не разбитой по частям) с 200 пользователями.
Sasa
214 - 06.06.2002 - 14:37
2(206) так сначала сделай - а потом занимайся чистописанием... Пока что ты переплюнул всех по громадности своих возможностей да по количеству писанного текста... Я тоже не вижу проблем построить из песка девятиэтажный дом - ну я же не лезу к строителям со своими умными замечаниями, не учу их жить...
2(209) маленькие и скромненькие люди сначала пойдут поучаться - и не три часа как ты это сделал (может даже и не сделал) Ты даже не знаешь сколько учиться необходимо...:)
БТР
215 - 06.06.2002 - 15:05
(213) Ты ЛИЧНО, когда нибудь занимался финансовым анализом? Сколько ЛИЧНО ТЫ можешь анализировать показателей в совокупности? 8? 10? Может быть даже 15?
И все таки, объясни причину, с какой стати остатки не могут формироваться оперативно?
Во-первых, документы ВСЕГДА поступают в хронологической последовательности. Просто нужно уметь закрывать дыры в документообороте. Прости, но я работал с ассортиментом в 200.000 позиций и документообротом на 12 складах, с ежедневным движением по 10.000 позициям. Так что не надо ля-ля, букой меня на понт не возьмешь. Мало того, все считалось по средневзвешенной цене в производстве, по средней скользящей в бухгалтерии, по партиям в ОМТС. И все это, без всяких пересчетов. Так что рекомендую кроме прямых рук иметь еще и светлую голову.
А во-вторых, давай не будем про комплексы. Это просто маразм, мой дорогой. Все должно быть взвешено и обосновано. Зачем мне зарплата в комплексе, если она считается раз в месяц? Ты сначала разберись со своим техническим могуществом. Если ты не понимаешь такого важного для функциональной декомпозиции показателя как регулярность данных, и никак не хочешь врубаться в то, что все оперативно-зависимые связи жестко выстраиваются только при необходимой регулярности меньше чем время подготовки и передачи документа (как единицы значимой информации) от отправителя к получателю.
Рекомендую все-таки не ограничиваться надуманными ограничениями, а думать головой, когда эти ограничения важны, почему они важны, как их можно обойти, и стоит ли это ограничение вообще учитывать, может быть проблема находится на более раннем этапе.
Удачи за пределами сабжа. Жди пока не получишь нужных тебе доказательств. Это твои проблемы.
(214) Ню-ню. На личности переходим? Прости, но я сначала предпочитаю думать и обсуждать, а потом реализовывать то, в чем уверен. Я тебя кажется уже спросил, КОМУ НУЖНО ЕРП, КОТОРОЕ НЕЛЬЗЯ РЕАЛИЗОВАТЬ НА 1С? Иди, учись своему SQL и убей в себе учителя. Здесь желательно обсуждать вопросы непредвзято. Меня лично мало волнует, что ты знаешь и умеешь. Меня интересуют конкретные причины твоей озабоченности девятиэтажными домами. И я спрашиваю - ты их видел? Я полагаю, что здесь все защитники крутости ЕРП работают на таких же предприятиях, что и защитники крутости 1С. Разве нет? А пальцАми мерятся - скучно. И гоношиться, что я мол практик, а ты теоретик - грубо и небезопасно. А вроде, взрослые люди. Развели тут детский сад. Что бы ты делал, критичный практик, без аналитиков, которые на основе плодов трудов тысяч практиков разрабатывают теории? Могут двадцать крутых практиков программистов не зная практики бухгалтерского учета, финансового анализа, менеджмента, маркетинга, логистики, мерчендайзинга написать ЕРП систему? Кишка тонка. Потому что кто-то должен копать глубины процессоров, а кто-то формализовать умения работы бухгалтера. Кто-то должен бороться с глюками и багами, а кто-то должен уметь построить архитектуру системы, кто-то должен успевать за день выполнить заявку, а кто-то должен уметь управлять проектами.
И, простите меня, глубокие практики, но для меня авторитет составляют те, кто в состоянии рассчитать и исполнить проект так, чтобы и программисты деньги получали хорошие, и клиенты были довольны и счастливы без авралов и истерик с обоих сторон.
Так что, у каждого свой рекорд. (С) Сок Чемпион.
Не надо убивать чужие мечты. Карма плохая.
Сок Чемпион
216 - 06.06.2002 - 15:44
2(215) - Кремлевский мечтатель
Sasa
217 - 06.06.2002 - 15:50
Манилов:)
БТР
218 - 06.06.2002 - 16:05
:)
Дразнитесь-дразнитесь. Я без внешнего сопротивления угасаю. :)
ppson
219 - 06.06.2002 - 16:39
>> что не надо ля-ля, букой меня на понт не возьмешь
я вижу что у вас повышенная самооценка, которая вдобавок еще подкрепляется только своим личным опытом.
Ну по средней кто угодно спишет. а списывать то и не надо. надо оценивать на конец периода по средней. Теперь что касаемо несредних оценок и документооборота, то простите сударь, он не всегда ведеться в хронологическом порядке - типичный пример - неавтоматизированные склады, когда документы от них поступают с какой то периодичность.
еще пример - транпортные расходы, поступающие от транспортных компаний в начале следующего месяца одной суммой на все перевозки за какой-либо период и которые надо распределить на стоимость МПЗ + возможность отсроченного поступления накладных от поставщиков + поступающая постоянно на склад продукция, себестоимость которой будет известна только когда это захочет бухгалтер закрывающий затраты + несколько складов, цехов и т.д., . Все эти и приводит к тому что при оценке запасов у тебя буду возникать переоценивающие запасы проводки и их реально может быть 50.000 за месяц.
Аналогично формирование финансового результата, если у тебя на всех счетах по одной аналитике то там все просто, а если их 5? и справочник по каждой штук по 100 и 10.000, то путем перемножения ты и выйдешь на большое количество закрывающих проводок, которые еще надо каким то образом распределять.
А зарплата не всегда платиться раз в месяц, она может начислятся и платиться и раз в неделю.
P.S. Если вы всю ERP систему сводите к анализу 10 показателей, то может зря голландцы, немцы и американцы пишут миллионы строк кода? может достаточно Excel?
Бука
220 - 06.06.2002 - 16:41
Эй, я внимательно все читаю и не собираюсь никого на понт брать :)
БТР
221 - 06.06.2002 - 17:18
(219) Перл сезона:
"я вижу что у вас повышенная самооценка, которая вдобавок еще подкрепляется только своим личным опытом"
Тут надо бы добавить еще что личным опытом повышения самооценки ;)
----
Правильно сделал, что не ушел.
Вопрос. Зачем оценивать на конец периода по средней? Можно прекрасно вести сквозной учет, независимый от периода. Каждый приход изменяет среднюю цену.
Что касается транспортных расходов, здесь проблема несколько раньше. С транспортной компанией отношения договорные и способ начисления транспортных расходов известен до того, как начинаются собственно движения. Поэтому, с точностью до 90% списывать затраты можно сразу по приходованию. Что касается неавтоматизированных складов, то они ВСЕ свои документы предоставляют пачками, и приходные, и расходные, в хронологическом порядке. Если это происходит не так, можно завести отдельный вид документа "складской ордер" для неавтоматизированных складов и свою последовательность для этого вида документов. Ну, и кроме того, какая может быть ЕРП, с неавтоматизированными складами? Только если общий оборот по этим складам составляет менее 4-5%, верно? А значит, ВСЕ движения по этим складам можно регистрировать сводом на дату поступления отчета от склада. И вообще пересчитывать тогда не надо.
Что касается отсроченного поступления накладных от поставщиков - это еще не значит, что неизвестна цена приобретения. Если неизвестна - ТМЦ принимаются на ответственное хранение, а при поступление накладной приходуются датой поступления. Бухгалтер, закрывающий затраты когда хочет увольняется по собственному желанию, и принимается бухгалтер, закрывающий затраты когда надо по четкому регламенту. Да, несомненно, переоценка запасов случается. Но, во первых не обязательно каждый месяц, во-вторых далеко не по всему ассортименту, и в третьих, количество переоценивающих проводок так или иначе будет в 10-15 раз меньше, чем количество проводок по движению ТМЦ.
И совершенно то же самое касается финансового результата. Да, при большом количестве аналитик проводок может быть очень много. Только у меня есть вопрос, сколько у вас статей в бюджете доходов и расходов? Какова минимальная граница точности вашего бюджета? Какая доля самой незначимой статьи, насколько она выше погрешности бюджета? Как много незначимых статей в бюджете?
Перевожу на русский язык. Процентов всего 100. Точность бюджета выше 97% это эксклюзив. 98% практически не достижимо. 99% - нонсенс, за который финансового руководителя можно увольнять как безответственного типа. Итого, погрешность бюджета в среднем составляет 2,5-3% для высокоточных бюджетов (что при неавтоматизированных складах абсолютно недостижимо)
Итого, мы можем сказать, что все статьи доходов и расходов, оборот по которым ниже чем 2%/4=0,5% являются незначимыми и должны быть сгруппированы в "прочие", так как они находятся в пределах ошибки бюджетирования и ни один финдир в здравом уме не будет копаться в таких статьях. То есть, если даже ВСЕ статьи оказываются незначимыми (ужас-то какой, ну и бардак в расходах должен для этого быть), то максимальное количество статей бюджета = 100%/0,5%=200. Логично?
Реально же, их намного меньше. Оборот по незначимым статьям не может превышать 20%. И тогда количество анализируемых статей - 20-30 как предельный максимум, уже вносящий определенную дезинформацию в структуру баланса.
Далее, что касается детализации затрат по подразделениям, видам деятельности, проектам, ЦФО, ЦФУ и прочее, прочее, прочее. Все проводки по этим разделам закрываются БЕЗ ПЕРЕМНОЖЕНИЯ. То есть, попросту говоря, мы имеем многоуровневое сворачивание незначимых показателей, и лишь затем реальное закрытие затратных счетов.
Ты уверен, что при создании вашей аналитической структуры проводилась оценка регулярности данных по различным статьям, проводилась оценка значимости статей и выравнивание укрупненных групп по значимости, а стати оборотов по статьям выравнивались по дебету и кредиту в соответствии с возможной регулярностью?
Видишь ли, нахрапом автоматизируя и ничего не оценивая можно и суперкомпьютер затребовать. И все будет работать, работать и работать. И уж конечно не на 1С. А если подумать?
Тот
222 - 06.06.2002 - 17:21
2(213) Типичный пример мифологизированного сознания. За "ИТРП+Инталев+Зарплата работающей единым комплексом (а не разбитой по частям) с 200 пользователями." платить ты будешь сам или найдешь кому кроме тебя это надо?
slw
223 - 06.06.2002 - 17:31
(221) В порядке самообразования - а что такое точность бюджета?
mikekk
224 - 06.06.2002 - 17:49
Да.... Пока олучался тут такие дела происходят....
(ppson) А ты хоть что-нибудь крупное в 1С делал???? Сомневаюсь. Иначе у тебя бы не было столь мало похожего на правду мнения о 1С. Позволь спросить, на чем это ты считаешь???? И кем работаешь???? Юзером, сисадмином, програмистом???? Вряд-ли третьим. И что-же у тебя за система такая. Если скажешь, что Галактика, смеяться буду долго.
(214) Милок. А ты кроме того, что-бы словами бросаться умеешь что-нибудь???? Я-ж тебя спрашивал про твои проекты. Ты делал что-нибудь крупное???? А ты про курсы..... Грусно.
mikekk
225 - 06.06.2002 - 17:50
(221) Поймут-ли????
БТР
226 - 06.06.2002 - 18:36
(223) Точность бюджета это такая величина, которая отражает достоверность прогнозирования значений финансовых показателей (например, прибыли, остатка денежных средств)
То есть, если по бюджету выходит, что остаток денежных средств составил 100 000 рублей, а реально в кассе 97 000 рублей, то мы имеем погрешность по показателю 3%. Если взвесить погрешности по всем показателям и рассчитать абсолютную погрешность, то получим, на сколько точность бюджета меньше 100%.
Разумеется, это приблизительный подход, потому что нужно учитывать регулярность данных, нужно учитывать значимость самих показателей и в общем случае даже саму точность вывести очень точно нельзя. И ее полагают выведенной статистически верно в том случае, если крайние значения отклоняются не более чем на столько же. Поэтому, я считаю уровень значимости статьи делением на 4.
slw
227 - 06.06.2002 - 18:45
(226) Тогда ещё вопрос: как связать фразу о неавтоматизированных складах и точности бюджета? Ведь даже если склад не автоматизирован, а тётя Маша руками выписывает накладные руками, потом эти документы все равно вводятся в систему и как следствие - данные доступны в системе
БТР
228 - 06.06.2002 - 19:01
(227) Чем больше нерегулярность данных (например, с одного склада документы поступают с задержкой в две минуты, а с другого - в два часа), тем меньше текущая точность данных. То есть, фактически, на складе находится ТМЦ на 100000 рублей, а в учете, на данный момент отражено только 90000 рублей. При этом, нерегулярность не позволяет получить более точную информацию статистическим усреднением, так как неизвестно, через какое время произойдет изменение показателя и на какую величину.
БТР
229 - 06.06.2002 - 19:11
Еще хуже, если по одному показателю существует разная регулярность по приросту и уменьшению. Например, если расходные накладные по складу регистрируются без задержки, а поступления на склад регистрируются только раз в день, то по сути дела отношение дневного оборота к остаткам на конец дня по такому складу можно смело списывать в погрешность. И абсолютно не имеет значения после этого, как быстро будут предоставлены данные о себестоимости продукции на этом складе. Потому что погрешность будет сравнима с самой этой себестоимостью.
Поэтому внедрение ЕРП это комплекс административных, организационных, проектных, технических и аналитических мероприятий.
Да, есть оперативные ньюансы, касающиеся оперативной зависимости разных разделов системы. Например, сбыту нужно знать, можно ли отпускать клиенту товар. Это значит, что во первых, клиент не нарушил договорных обязательств, а во вторых, внутренние службы готовы исполнить наши договорные обязательства. И для этого вовсе не обязательно знать конкретный остаток на складе. Достаточно знать, что склад оформил соответствующий резерв.
Практически же, из нескольких тысяч возможных взаимосвязей каждое конкретное предприятие имеет пару десятков своих. И совершенно необязательно, что выбранный документооборот действительно оптимален. А ведь ЕРП нацелено на внедрение типового оптимизированного документооборота. Но оптимизированного - не значит оптимального, верно?
Dich
230 - 06.06.2002 - 19:17
(восхищенно и с должным пиететом)
Ну народ :-))))))))))) блин, даете!!!!!
А как вам насчет того, что БТР прав, и ERP действительно - процессы, которые должны отражаться в информационой системе предприятия.
А вот тут мы и подходим к определению информационной системы. Никогда это не было решено в рамках одной программы. По крайней мере на наших просторах. Всегда параллельно с основной учетной платформой сосуществуют расчеты, проводимые в Екселе, еще где-нибудь, выгрузки/загрузки данных, ОЛАПЫ и др... На мой взгляд реальнее поставить 1С в центр такой ИС, и окружить ее модулями, написанными на чем угодно, но на том, что максимально подходит для решения конкретной задачи...
И все сразу становится на свои места. Правда, встает вопрос - а зачем 1С? АА вот зачем - внедреж на работающем предприятии будет долгим и "бархатным", если нет желания завалить работу этого самого предприятия. А на предприятии 1С уже есть...
slw
231 - 06.06.2002 - 19:20
Автоматизация бардака приводит к появлению автоматизированного бардака. Случай из практики: Клиенту поставил отчет по продажам. При этом сумма продаж хранилась в руб., а выводилась в валюте удобной клиенту. Курс пересчитывался на конец периода(месяц). Клиент наехал - ошибки в отчете. При разбирательстве выяснилось, что клиент считал курс на каждый день и складывал. Отмазки типа: средняя ошибка составляет 0.25% не прошли, мне заявиил, это $10000. А ты говоришь 3-5%
p.s. Теперь моя любимая фраза - Без ТЗ даже ворона не каркает!!!
?
232 - 06.06.2002 - 19:21
Есть три склада. Какой из них должен оформить этот резерв?
И должны ли мы вести разговор с клиентом, не зная есть ли товар на складе? Может везти его три месяца, а мы пишем в договор срок поставки месяц. Платить штраф?
Как узнать, не нарушил ли клиент своих обязательств, если он работает по разным договорам с разными подразделениями, а база у нас разроблена? Отгрузить с превышением кредита на пару десятков тысяч? Или пусть он ждет момента синхронизации данных?
slw
233 - 06.06.2002 - 19:30
(232) Автоматизация бардака - автоматизированный бардак. Как и что можно у вас внедрять если не определены основные принципы работы с клиентом и товаром? Как фирма вообще может работать если там ничего не известно? По моему опыту ВНЕДРЕНИЕ, т.е. ПЛАНИРОВАНИЕ, создание системы учета, обучение пользователей и пр., сразу выявляет многие узкие места документооборота. А исходя из вышеприведенной фразы имеется только учет ради учета, но никак не для принятия управленческих решений.
БТР
234 - 06.06.2002 - 19:38
(232) Здесь нет ни одной технической проблемы. Чистой воды бардак в организации в системе сбыта. Уж если товар могут везти ТРИ МЕСЯЦА (!), то неужели это так сложно иметь информацию по свободным остаткам (за минусом резерва и минимального остатка компенсирующего разрыв в регулярности)?
(231) Во-во :) Правда, при том, что идеала не достичь, нужно во первых трезво взвешивать соотношение рисков наведения порядка/автоматизации бардака, а во вторых, чутко контролировать моменты наступления рисковых ситуаций.
?
235 - 06.06.2002 - 19:44
То 234. В ТРИ МЕСЯЦА :)) входит и срок производства - оно может быть серийным. Ну не производит в данный момент эту серию фабрика.
Так все же п. 229 - "вовсе не обязательно знать конкретный остаток на складе" ???
slw
236 - 06.06.2002 - 19:52
(235) Опять таки из личного опыта:в конторе производящей окна, в прайсе/договоре указывается срок исполнения заказа по профилям №№ 3 дня, по профилям №№ до 1месяца т.к. надо заказывать в Германии, по профилям №№ сроки исполненния закза согласовывать с менеджером (типа, а может их сосвсем нет и больше не будет.
Но это совсем не означает что срок поставки от поставщика 3 месяца, а покупателю 1 месяц относится к техническим проблемам. Это проблемы сбыта/юр.службы. Одним словом БАРДАК.
Шаров
237 - 06.06.2002 - 19:52
Насколько я понимаю кубик – это обособленная функциональность АСУ, отражающая обособленный же кусок предметной области (например, планирование, оперативный склад, производство, финансы).
1. Действительно ли в предметной области существуют обособленные куски или это только вопрос методологии управления предприятием?
2. Как делить функциональность на кубики, чтобы минимизировать данные, требуемые более чем одному кубику? Есть ли работы, сравнивающие подходы от разных АСУ?
3. Полагаю, ERP, постулируя наличие обособленности в предметной области, предлагает набор кубиков для АСУ. Знает ли кто-нибудь хорошие концептуальные работы, описывающие методологию ERP без привязки к конкретной АСУ?
БТР
238 - 06.06.2002 - 20:08
(235) Вовсе не обязательно. Могут быть другие решения. Допустим, достаточно знать, что на складе резерва для этого клиента нет и этого товара нет в минимальном запасе (или оперативном резерве). Это и называется планирование. Если структура складских остатков по резервам известна, то какие могут быть проблемы? А все резервы создаются в офисе.
(237) Здоровски. Умеешь же ты вопросы задавать :) Сам бьюсь. Может кто куда натолкнет?
БТР
239 - 06.06.2002 - 20:14
(235) Если точнее, вот формула.
На складе лежит товар А 20 шт для клиента X, 50 шт для клиента Y, 30 штук для клиента Z, оперативный резерв - 20 шт.
Какая разница, кто из клиентов X, Y или Z сегодня приедет или не приедет забрать товар и в каких количествах? Ведь совершенно очевидно, что мы можем располагать для новых клиентов только количеством 20 штук, которые НАВЕРНЯКА на складе есть.
slw
240 - 06.06.2002 - 20:24
По моему пример некорректен. Ведь если у нас товар просто зарезервирован и неизвестно когда за ним приедут то как можно вообще планировать отгрузку(какой же это ERP). А если сказано, что зарезервировано на завтра 100шт, а на складе 20шт это какой процент выполнения плана - 20?:)) И что можно сказать о том кто так планирует - гнать его надо!!!.
БТР
241 - 06.06.2002 - 20:33
(240) Видишь ли, ты спешишь с выводами. Да, действительно, товар резервируется на определенные сроки. При этом, за то, чтобы товар БЫЛ на складе отвечает снабжение (или производство). Если какой-либо товар НЕ ПРИБЫЛ ВЧЕРА, он просто резервируется за счет оперативного резерва. И если произошел перебор оперативного резерва, об этом будет извествно еще ДО НАЧАЛА РАБОЧЕГО ДНЯ. Соответственно можно принять решение, предупредить клиентов, переместить какие-то резервы на более поздний срок и т.д.
Главное, что любая ситуация имеет свой набор решений, каждое решение имеет разные сроки исполнения, разный риск и разную стоимость. Но недаром системы класса CRM считаются наиболее перспективными. Ведь финансовый план начинается с бюджета продаж.

242 - 07.06.2002 - 09:42
Хм.. оригинальные мысли..
?
243 - 07.06.2002 - 09:54
Уже лучше. А то 236 фигню было понес. Бардак-бардак... Это нормальная работа со многими категориями ТМЦ. С такими воплями можна доавтоматизироваться до того, что умные автоматизаторы будут жить сами по себе, а тупые менеджеры сами по себе. На кой им такая умная автоматизация, если работать невозможно.
То 239. У вот тут ты не прав на 100%. Не можешь ты планировать не то что резервы - даже продажи с детализацией по каждому товару. Пришел клиент и забрал весь твой "оперативный резерв". Через 15 минут пришел второй клиент - и забрал его же. Или как? Сказать:"Да пошел ты! Ты в план не вписываешься!". ИМНО незнание остатков некоторый перебор.
Jane
244 - 07.06.2002 - 10:31
Бука - молодец! ТАКУЮ тему открыл, столько интересного, люди грамотные (особенно БТР, чувствуется академическое образование). А все почему - начался у нас (в России в смысле и ее бизнесе) этап не просто "купи подешевле - продай подороже", а "прими оптимальное решение". Приходят наши бизнесмены к тому мысли, что НАДО планировать, бюджетировать и, в итоге, увеличивать прибыли. Но не ясно им еще как, кто и каким образом. И нам, спецам, не ясно, каким образом их неясности реализовавыть.
А реализовать можно что угодно на чем угодно. Вопрос только сколько человеко-часов на это потребуется.
Извиняюсь, что встряла в ваш умный разговор.
ppson
245 - 07.06.2002 - 10:49
224) - реализовал к вашему сведению проекты. и все крупные. и работал не только программистом на этих проектах. И хочу тебе сказать, что когда у тебя количество пользователей начинает переходить за 50, ты начинаешь думать о том как обходить так называемы особенности клиент-серверной версии 1C. Маразм был и останеться - одна транзакция в один момент времени. уже отмерло в конеце 80-нач. 90. Если вы почитаете мое мнение об 1С, то увидите что я ни слова не сказал что она кривая и язык у неё плохой. Граблей с движком у всех хватает, но у 1с этот движок даже не компилируется в байт код. Что то типа Вижуал Бейсика для Офиса.
Могу вам рассказать пример: в одной московской фирме отдел автоматизации боролся с немаштабированностью 1С путем TSE и так далее. В конце концов когда уже все это встало у горла, был написан отдельный движок для SQL, а в 1С только формы документов, справочников, отчетов и т.д. Не было модулей проведения и так далее. Все общение с базой было через OLE путем использования этого движка. Я НЕ ГОВОРИЛ, что на 1С невозможно написать систему класса ERP, CSRP или какой нибуть другой Пи. Я говорил только о том что 1С слабомаштабируемая система. Ну а если говорить на эту тему то ERP можно писать и на VBA на ACCESS. алгоритм можно перенести на любой язык. вопрос в том с какой скоростью это все будет выполняться.
БТР) Я к несчастью для вас не специалист по бюджету, этим занимаются специально обученные люди, поэтому ваше цитаты можете оставить для любой другой публики, кроме меня.
Теперь вернемся к логистике - вы не правы много много раз.
То как вы работаете с пользователя - давно уже пройденный этап, который был пройден еще в 1998-1999 годах, когда еще было 7.0 и 7.5.
Для того что бы формировать оценку запасов по методикам ФИФО и ЛИФО, не надо заставлять вводить документы в хронологическом порядке. и ни в одном описании модулей управления запасами или логистики любой ERP системы вы не увидите это. причин может быть много - раные накладные могут контролироваться с разными сроками, отсюда и разное их окончательное проведение по базе. (67) это ясно пояснил, так как в 1С невозможно провести планируемые проводки а потом их зафиксировать в системе. никакому управленцу не нужно знать на теперешний момент точную стоимость запасов, ему нужно точно знать их количество. точная суммовая оценка может быть приближенной. причины я называл - нет себестоиомсти полуфабрикатов и продукции (а никакого бухгалтера не уволят если он посчитает себестоимость в следующем месяце, а уволят как раз того кто посчитает их в текущем месяце), нет подтверждающих накладных от поставщиков (а ТМЦ полученные от поставщика уже в этот же день могут быть списаны в производство или проданы или передены на другой склад). Договор с транспорной компанией может быть заключен с поставщиком, а покупатель может оговорить что он будет оплачивать не более n% от суммы ввезенной за месяц ценностей, т.о. нельзя точно оценить примерную стоимость транспортных расходов, они могут быть и n% могут быть и меньше.
Особенности определения количества товара - например переобмеры круглого леса, могут заставить поставщика сторнировать задним числом отгрузки.
Вот поэтому в MRP системам присутствует так называемые способы оценки МПЗ на отчетную дату, которые и формируют сотни и тысячи проводок для определения точно стоимости запасов. БТР, у меня нет сил цуитировать руководство по управлению запасами, почитайте их.
Если даже вас и это не убедит могу предложить другую система класса ERP - банковская. вот - на начала дня или конец дня надо посчитать проценты по миллионам счетам. и все это даже на их оборудовании занимает длительное время. теперь вы представляете, что будет если в момент проведения данного документа в системе написанной на 1С вся работа банка просто прекратиться. очереди у банкоматов ...
Тот
246 - 07.06.2002 - 11:17
2(245) Ну здесь ведь речь то не про то. Отдай мне 10-15% той суммы, которую ты за SAP выложить собрался. И не будешь ни с чем возиться...
ppson
247 - 07.06.2002 - 11:21
246) Я за сап деньги не выкладываю.
Я сап не занимаюсь.
О чем тогда со мной спорит БТР?
Тот
248 - 07.06.2002 - 11:45
247) Он с тобой не спорит. Он просто продвигает мысль о том, что "мифологией" заниматься надо, когда деньгу у клиента выдуриваешь. А не на профессиональном форуме. Тут то дурить народ - ну никакого смысла.
Насчет банка тож не гони. Знаем мы ихние проблемы... Предложили вот внешнюю компоненту "Опердень" сделать... Только вот сами не могём. Поскольку ее сертифицировать надобно. А там по этой части все схвачено...
ppson
249 - 07.06.2002 - 11:48
248) - ты в банке работал? если нет тогда вот сам пожалуйста не гони.
В банках проблем нет.
Тот
250 - 07.06.2002 - 12:02
Работал. Устраивает? Я на ВЦ. Жена - в самом банке. Ей главбуха предлагали должность - дело было. Стаж у ей банковский - 15 лет. Вот сертификат аудиторский по банкам получать надумала... Серии "Б"...
Проблемы в банках есть. Как и везде. Просто гнать не надо. Гонивометр зашкаливает.
А внутрихозяйственный учет уже в двух банках на 1С сделали. Так. Для справки.
Тот
251 - 07.06.2002 - 12:09
"Под конец скажу о мечте. Ужасно хочется сделать систему в банке (когда-то в банке работала). У меня друзья работают программистами в банках, в организациях, создающих программы для банков. Я думаю, они строят карточные домики с помощью мощных программ (вытащил карту снизу - и все рухнуло). Хотелось бы попробовать в "1С", где все менять можно "наверху, а не внизу". Я не программист и недостаточно представляю это себе. Но думаю "1С" дорастет."
http://www.lvt.kiev.ua/opus/opus4.htm
Правда, давно это писано... Но причина - она ОЧЕНЬ ХОРОШО знает, что банкам надо...
:)))
252 - 07.06.2002 - 12:12
"внутрихозяйственный учет уже в двух банках" - это метлы уборщиц считать. Зато как гордо звучит!
Глупость
253 - 07.06.2002 - 12:17
Слабо на 1С написать среду в которой работает биржа :)
Тот
254 - 07.06.2002 - 12:21
2(252) А что? Не надо метлы считать? Обидно, что гордо звучит?
ppson
255 - 07.06.2002 - 12:24
250) -
1. Каждый разговаривает в меру своей начитанности. Я на личности не переходил.
2. Я тоже работал в банке 5 лет. и хочу вам сказать что автоматизация хоз.учета в банке и автоматизация финансовых операций - две больших разницы. Маштабами. Так же как и автоматизация сберкассы где сидит 20 бухгалтеров и головного офиса банка где работают почти тысяча клерков онлайн, и каждую секудну происходит сотни и тысячи транзакций.
3.Каждому продукту своя область применения. Если 1С 7.7 абсолютно не толератна и не маштабируема, то её никогда не посадят на критические области.
4. Очень хорошего вы мнения о своих друзьях программистах.
5. Спор в сабдже напоминает спор любителей VB и Delphi. Что быстрее и лучше.
6. Когда 1С дорастет, можно говорить о увеличении её области применения. За 5 лет что на рынке 7.* можно было бы обновить хотя бы раз технологию, которая умерла в конце 80х-нач. 90 годов, когда все писалось на FOX или PARADOX.
Северянин
256 - 07.06.2002 - 12:27
Народ, да успокойтесь Вы! Не нужно доказывать кто круче! Тема действительно интересная. И давайте пока отойдем от платформы на которой будет реализовано ERP, а поговорим о собственно технологиях Управления бизнесом.
ppson
257 - 07.06.2002 - 12:30
250)Проблемы не у банков, а у тех людей которые там работают. как и везде.
Тот
258 - 07.06.2002 - 12:57
Мифологам всех мастей:
1)Не надо нас пугать. Операционный день банка - суперпримитивная задача по управлению движением денег между клиентами и корсчетами. Ее вполне можно на экзамене на сертификат за 4 часа решать... Другое дело - там есть проблемы безопасности, контроля и пр... Самое главное - что работать с деньгами клиентов можно только на сертифицированных программах. А для сертификации нужен код... Только поэтому решить проблему ОДБ в 1С невозможно. Выход - внешняя компонента. А внутрихозяйственный учет в банках на порядок сложнее, чем ОДБ. Это для тех, кому действительно интересно. А не мифологов. С тысячей транзакций в секунду. В голове.
2) Кончайте гнать. Говорю же - гонивометр зашкаливает. (253) Это к тебе относится в первую очередь. А вдруг работа биржи - это тоже суперпримитивная задача? Я не знаю. Думаю, ты тоже.
Глупость
259 - 07.06.2002 - 13:24
1. По поводу биржи - на 1С - нельзя этого создать в силу ее архитектуры и быстродействия :(... требования к такой системе и описание системы которая работает на ММВБ с кину вечером, сейчас на память я все не помню - а п..ном прослыть не хочется...
а вообще я считаю этот спор довольно глупым - я на 99% согласен с БТР - что если правильно описать весь документо оборот и фин потоки предприятия - то это может быть и возможно реализовать на 1С. только мне кажится что люди, которые дорастут до того что бы реализовать такую систему - скорее всего пререйдут в более высокий разряд всеж за САП платят больше :(
см объяву (осталось только узнать что такое модуль FI и вперед в бой )
07.06.02 11:23 | Требуется Консультант по внедрению SAP R/3 (модуль FI)
мужчина, 24 - 40 лет. Образование - высшее.
Опыт работы - свыше 2-х лет.
Город: Москва
На постоянную работу. Полный рабочий день.
Зарплата от 3000 $/месяц
Дополнительные сведения:
в/о, опыт аналогичной работы от 2-х лет. Прекрасное знание модуля FI, бух. учета GAAP, налогового законодательства.
так, что, набрался опыта в 1С - и надо пытаться идти в сап...
ppson
260 - 07.06.2002 - 13:28
258)
1) - согласен. алгоритмов расчета процентов немного и они достаточно быстро выполняются. но когда их сотни тысяч и миллионы то перемножением ты получишь очень длительное время выполнение всего процесса.
Внутрихозяйственных операций в банке в день на несколько порядков меньше чем финансовых. Хоз.операции в банке не намного сложнее чем на любом другом предприятии. Особенности только в корреспонденции счетов и отсутствии активно-пассивный счетов (по действующему плану счетов).
Насколько я помню вы из Украины (сорри если ошибся) и может он у вас сложнее и чем то отличается от российского.
2) Когда дискурсия доходит до данной аргументации, то её лучше всего прекратить.
ZhV
261 - 07.06.2002 - 13:44
To ALL
Прошу прощения - все-таки встряну.
Тот - авторитетный абориген Т1С.
Но не принимайте на веру его мнение о примитивности банковских систем.
Не поленитесь ознакомиться с функционалом , требованиями по производительности, масштабируемости, надежности систем приличных
контор - ПрограмБанк,Диасофт,ЦФТ,CSBI ... Сертификации в РФ подлежат
только модули по работе с госконторами таможня,РКЦ,...
Есть издание "Банковская техника и технологии" .
Дискутировать в очередной раз не буду.
Северянин
262 - 07.06.2002 - 14:43
А можно ли средствами 1С реализовать CSRP?
...
Рассмотрим следующие вопросы:
Сможете ли Вы...
1. Определить наиболее многообещающие и прибыльные рынки для Вашей компании?
. Установить какие рынки и товары наиболее прибыльны?
. Предсказать какие рынки будут наиболее прибыльными в течение одного года? В течение шести месяцев?
. Планировать и работать в направлении к более прибыльным рынкам?
. Гарантировать своевременную поставку наиболее ценным покупателям? Всем покупателям?
. Точно предсказать время поставки для уникальных заказов?
. Удовлетворить запросы покупателя в течение 24 часов? В течение 8 часов? В течение 1 часа?
. С прибылью видоизменять продукты и услуги?
Это очень важные вопросы и еще не так много производителей, которые могут уверенно ответить "Да", на большинство из этих вопросов. Прежде всего причина заключается в том, что многие руководители первым делом фокусируют свое внимание на производстве и большинство из них смотрят на улучшение текущей деятельности, а не на определение рыночных отклонений или слежением за покупательскими предпочтениями.
www.cfin.ru/vernikov/mrp/csrp.shtml(с)
ppson
263 - 07.06.2002 - 14:46
262) Можно.
Sasa
264 - 07.06.2002 - 14:53
Авторитет - это не поклонение у ламеров, а все таки признание специалистов:)
PS
265 - 07.06.2002 - 14:54
А еще 1С выдает замечательные прогнозы погоды. Оправдываемость высокая.
Andy22
266 - 07.06.2002 - 15:01
Понадобилось одному человеку возить скажем кирпичи. Посмотрел он рекламу и решил купить ИЖ. Хорошая машина, кузов оцинкованный, и цена совсем маленькая. Купил. Попробовал повозить кирпичи - возит! И быстрее грузовиков, пусть и поменьше за раз, и комфортнее, а главное - значительно дешевле как сама машина так и бензин для нее. И все бы было замечательно, но вот все же маловато кирпичей за раз она перевозит. Ну что же - поехал в СТО, срезали ему заднюю часть кузова. Теперь стало вобще зачипись. Кирпичей много влазит, а переделка не так уж и дорого обошлась. Он начинает всем знакомым советовать - мол, нафига вам дорогущие грузовики, покупайте ИЖ. Если где не тянет - переделать можно, кузов грузовой приделать, прицеп прицепить, движок помощнее поставить.
Вот такая вот замечательная история, только вот пока она не заканчивается.
Прошла неделя и вдруг полопались у машинки пружины от нагрузки. Пришлось ставить пружины помощнее. А поскольку не выпускают для ижачка такие пружины, пришлось ставить от другой машинки и хорошо заплатить дяде Васе с СТО что бы он их впихнул.
Только поменял пружины - тут другая напасть - кузов перекосило, стали двери на ходу открываться. В результате уже не езда, а мучение, как бы кирпичи по дороге не растерять. Потом движок износился, хотя вроде бы должен еще работать и работать. Стекла стали лопаться, халтурно поставленный пружины иногда вылетают.
Так и мучится мужичок до сих пор, платит деньги за постоянный ремонт, кирпич то возить нужно. А на грузовик нормальный денег нет, все в апгрейд ижа ушли.
Вот такая вот грустная история. Выводы делайте сами.
ppson
267 - 07.06.2002 - 15:06
262) Действительно можно. и потуги есть, например у Астрософта появилась скажем так урезанная CRM решение. но оно все сведено только к оформлению информации о клиенте или потенциальном клиенте
ex-Alex
268 - 07.06.2002 - 15:07
Е-ма-е! Сколько я пропустил! Оказывается шоу продолжается!
Северянин
269 - 07.06.2002 - 15:12
2(266) Очень поучительная история, которая моглабы быть такой:
1.Хорошо мужичок посчитал, купил ИЖ получи прибыль от своего бизнеса, понял что нужно развиваться, на накопленные денежки купил Бычка (грузовичок такой). Снова окупил его и купил Камаз и тд.
А все почему? Потому что начальный Капитал небольшой а голова большая, хорошо считать умеет. А если бы он сразу купил Грузовик, то ему пришлось бы денежки то занимать, а где? Куда не сунься в банк или к "имеющим деньги", везде поставят в такие условия, что так и будет работать только на отдачу долга и ни какого развития.
Andy22
270 - 07.06.2002 - 15:19
2(269) Все оно так, только вот в начале Бычок покупать денег жалко, и так все работает. Да и должен же ижак хотя бы свою стоимость окупить. А потом вобще наступает разочарование в автомобильных системах, и мужичок просто нанимает десяток других мужичков из деревни с лошадками и тележками.
Тот
271 - 07.06.2002 - 15:19
2(266) Вот вам и очередной миф.... Из него следует - на Delphi - можно. На 1С - нельзя. Прямые запросы к SQL из VB работают быстрее, чем из 1С, потому что не из той среды выродились. Хотя и текст одинаков...
Andy22
272 - 07.06.2002 - 15:28
2(271) Ага, Тот, вот ты и попался. Я ведь специально от конкретики отошел. Где речь шла о Дельфи, SQL и иже с ними. Вспоминая народное правило психоаналитики: "У кого что болит тот о том и говорит" :)
А если серьезно - речь шла не о скорости выполнения SQL запросов, не о скорости всей платформы даже. А о том какие усилия надо приложить чтобы создать, и, главное, поддерживать систему в актуальном состоянии, да еще развивать ее при этом.
slw
273 - 07.06.2002 - 15:32
(270)Так в (269) было сказано "Мужичёк УМНЫЙ" - он знал зачем ИЖ покупал. Для моделирования транспортного бизнеса, для накопления начального капитала и пр.
Северянин
274 - 07.06.2002 - 15:38
2(270) Да у мужичка и права-то только класса "В". И вообще ему может не кирпичи нужно былобы возить а например сигареты по киоскам. Или вообще заняться другим бизнесом. Но если он начнет с развозки сигарет и для этого сразу приобретет КАМАЗ, то скорей всего его бизнес быстро загнется, и не потому, что КАМАЗ плохой! Всегда нужно начинать с Проекта (бизнес-плана). И уже на основе проработанных решений управления бизнесом выбирать систему поддержки этого бизнеса. А если сначала купим Большую систему, а потом будем дкмать как ее пристроить к "местным условиям", то это просто выброс денег.
Вспомни те начало автоматизации года 70-е.
Буржуины начинали автоматизацию с того, что перестроили существующие системы управления бизнесом под требования автоматизации и уже на этом получили эффект (и деньги на автоматизацию).
А у нас в СССР начинали с покупки ЭВМ, а потом думали как же ее загрузить!
     
Andy22
275 - 07.06.2002 - 15:55
Еще одна история. На этот раз реальная.
Был у меня сервачок. 2хPII-450, 256М памяти и 1 SCSI диск (баракуда, старая еще на 7200)
Купил я новый - 2xPIII-1.26, 1G памяти, RAID-5 из 15-титысячников.
Стало все побыстрее работать, но не особенно то быстро (я про 1С речь веду).
А дальше все совсем плохо. Чтобы увеличить быстродействие сервера на x86 платформе, за каждые 5-10% прироста производительности надо платить бешеные бабки. Столь пугающие здесь народ Саны с определенной планки быстродействия начинают стоить дешевле чем x86 сервера, а с определенного момента быстродействие для x86 машин становится просто недостижимым. А 1С на все не х86 путь заказан.
Но дело то даже не в этом - уже упоминавшийся мною сервер на самом деле не особенно то и нагружен, и быстродействие увеличилось в основном из-за уменьшения времени доступа к дискам.
Практически нулевая масштабируемость 1С это причина номер раз почему не стоит использовать ее в тяжелых проектах.
Причина номер два - кто нибудь решится использовать 1С в системах где 10 минут простоя обходится скажем в $10K? Только честно.
Причина номер три - полное отсутствие контроля версий, автоматического обновления и т.п. Вы всерьез считаете что в больших проектах без этого можно обойтись?
Есть еще куча причин, но эти три самые больные.
Andy22
276 - 07.06.2002 - 16:01
2(274) Да кто же с этим спорит? Мораль то истории совсем не в том. Предприятие, о котором речь, уже доросло до ERP (Мужик и раньше кирпичи возил, и деньги у него уже есть, даже на грузовик, он ведь между грузовиком и ижом выбирал).
ppson
277 - 07.06.2002 - 16:02
275) - все эти аргументы приводились, но люди все равно не поняимают, или не хотят понимать.
------------------------------
Всем удачи. Хороших выходных и до понедельника.
slw
278 - 07.06.2002 - 16:11
(275)Встречная история - был сервер TS 2х400 Celeron загрузка 100% -> 2х600 загрузка максимум 80% быстродействие возросло не на 50, а на 78%. Вывод: апгрейдить нужно критические цчастки.
А насчет $10К за 10мин - при таких объемах система режется на несколько частей. Про это БТР достаточно подробно расписал.
БТР
279 - 07.06.2002 - 16:40
Люди, о чем вы? Причем тут ERP и банки? Причем тут ERP и 10Килобаксов за 10 минут простоя?
Вы хоть в ключе обсуждения держитесь. Никто же не говорит, что системы класса ERP подходят для управления атомной электростанцией! Для этого нужны специальные технологические системы. Поэтому нечего приплетать к проблемам платформы 1С то, что нереализуемо и в классических ERP-системах.
Мы тут что, за Родину сражаемся, друг-дружку в грязь затаптываем или все-таки обсуждаем реальные проблемы реализуемости КОНКРЕТНОЙ ФУНКЦИОНАЛЬНОСТИ ERP на платформе 1С? Или состязаемся в остроумии, красноречии - кто круче метафору закрутит?
Давайте все-таки вернемся к конкретным проблемам конкретных предприятий.
Думаю, что гораздо полезнее будет обсуждение тех проблем, которые мы знаем из практики. Пора бы уже успокоиться и уйти в новую ветку.
Предлагаю так. Кто-либо, уверенный, что знает КОНКРЕТНУЮ ситуацию, которая является ОРГАНИЗАЦИОННО ОПТИМАЛЬНОЙ, но принципиально нерешаемой средствами 1С, и типично решаемой какой-либо конкретной (и реально работающей ERP-системой) открывает новую ветку. А мы совместно обсуждаем, как это могло бы быть решено на платформе 1С, либо реорганизовано.
Окей? Пора этот флуд убивать.
Северянин
280 - 07.06.2002 - 16:59
2(279) БТР, полностью согласен. Пора действительно открыть ветку : Как реализовать проблемы Предприятия по управлению ресурсами средствами 1С.
Sal
281 - 07.06.2002 - 17:49
Интересно никого не посещала мысль сравнить ресурсы затраченные на создание Oracle Applications или SAP и верхнюю грань того, что удалось написать на 1С (даже если верить всему что написал БТР в 46)-они отличаются не одним порядком, наверное, не просто так.
Ключевая мысль: с покупкой нормальной системы управления предприятием, вы получаете информационную модель, которая прошла некоторое количество внедрений на предприятиях и вобрала в себя все лучшее (прозрачность и не запутанность процессов), отбросив всякую ересь имеет постоянную поддержку... И вот вы ставите
эту программу и все (все компоненты вашего предприятия) начинают учиться нормально работать, акции расти, и т.д ....
Тот
282 - 07.06.2002 - 18:59
2(281) Посещала, конечно. Тут народ даже идею высказывал, что можно программу сделать с одной кнопкой. На весь экран. И при переодическом ее нажимании все само делаться будет.
А БТР - он хитрый. Он знает, что никто ничего конкретного не скажет. Потому как давно бы все это известно было. Что вот нельзя решить задачу в 1С, сформулированную в терминах учета - и все тут.
У народа ведь какие аргументы "А вот 1.000 юзеров в 1С в одной базе сидеть не могут!". Что в переводе означает "Я не умею решать проблемы автоматизации никак по другому, кроме как 1.000 юзеров в одну базу воткнуть"...
Вот и весь сказ.
mazzy
283 - 07.06.2002 - 19:15
Тот 282: "Он знает, что никто ничего конкретного не скажет. Потому как давно бы все это известно было. Что вот нельзя решить задачу в 1С, сформулированную в терминах учета - и все тут."
.
Вот, Тот, БТР, это задачи, которые не решаются на 1С.
1. трехвалютный учет в бухгалтери (mazzy.ru/exercise/tt/multicurrency/);
2. будущие (плановые, бюджетные) проводки на регистрах, не запрашивая информацию с начала деятельности предприятия;
3. работа со временем во всех компонентах 1С (учет времени, планирование времени, календарное планирование не только по датам).
.
Решайте сколько пожелаете... хоть с нуля ваяйте... если будете привлекать компоненты, то обоснуйте и обясните где кончается 1С и начинается нестантартная программа :)
.
Если вам не нравятся ограничения (например, в п.2) то обоснуйте стоимость решения без этих ограничений.
.
Уверен, что решите. Вы же все можете. Только объясите пожалуйста стоимость вашего решения и стоимость поддержки. Хотя бы в часах работы.
.
Про типовые даже говорить не буду...
БТР
284 - 07.06.2002 - 19:29
(283) Не так быстро, mazzy :)
Будь добр, ставь вопросы не технические, а аналитические. Иначе, мне не совсем понятен смысл этих задач. Короче говоря, ЗАЧЕМ ты считаешь необходимым применять перечисленные тобой технические решения.
Конкретно.
1. В каких ситуациях нужен трехвалютный учет (пойду, посмотрю, что там у тебя по ссылочке)
2. Что ты подразумеваешь под будущими проводками на регистрах, конкретный пример, пожалуйста
3. Приведи, пожалуйста конкретный пример с использованием времени, судя по тому, что тебе нужно - сквозной, то есть, бизнес-процесс, в котором время появляется и бизнес-процесс, где затем это время используется.
-----------
Давай не будем бежать и затаптывать не глядя, а попробуем пойти медленно и решать конкретные задачи всесторонне. Так интереснее.
Я открываю новую ветку "Задачи класса ERP, которые не решаются на 1С" и цитирую твой и свой посты. Окей?
mazzy
285 - 07.06.2002 - 19:54
1. сходи все же по ссылкочке :). Это нужно для учета в корпоративной валюте. Если проще, для цветного учета.
2. план/факт на регистре. :) Ты уже отвечал в этой ветке. Я тебе уже говорил, что твое решение неприемлимо по производитльности.
3. я уже говорил. например, планирование производственных процессов.
Ок. я туда же помещу ответ...
ЗЫ по первой задаче тут уже копья ломали. решения нет до сих пор :)
mick_777
286 - 09.06.2002 - 12:15
я бы согласился с БТР, но:
1. Сколько у тебя будет отдельных баз 2, 3, 5 или 20? и как ты будешь их синхронизировать?
2. Любое изменение в МД требует разогнать всех пользователей. попробуй разонгать 10 человек. В "нормальной" конторе "повесят" за это.
3. "скорость" мне пришлось просидеть 2 недели чтобы перестроить 1С отчет в запросы напрямую к SQL и результат: 10 секунд против 40 минут вместе с зависанием 100% ресурсов на серваке !!! это же маразм.
Нет уж. если нужна хорошая хRP система, то надо переходить на другой
уровень, и не обязательно SAP, например та же Axapta на порядок дешевле, и среда разработки там гораздо мощнее, и наработок мировых в ней предостаточно. Зачем заново изобретать велосепед. БТР, не лучше ли сместить свой потенциал не на изобретение велосипеда а на доработку мерседеса.
БТР
287 - 09.06.2002 - 13:36
(286) Если бы в свое время братья Райт занимались доработкой телег, то что было бы с самолетами? :) Логика в этом есть, несомненно. Правда, я пока ремонтирую велосипеды, на фоне проектирую космический корабль. Тварь я дрожащая или право таки имею? :)
Jane
288 - 10.06.2002 - 06:37
Люди, что Вы спорите! 1С для малых и средних предприятий. Если на среднем предприятии нужен ERP, то средствами 1С их уровень ERP можно реализовать. Ведь на среднем предприятии нет 7000 проводок в день. И 1000 юзеров тоже нет. И анализ делают не чаще 1 раза в день. Прав тут БТР, оптимизировать схему сначала надо, а потом уж ее автоматизировать. Если глбуху кажется, что нужно 7000 проводок в день, это еще не значит, что все они на самом деле нужны. А когда предприятие вырастет из среднего в крупное, вот тогда и назреет переход на новые платформы. Но, опять же, опыт автоматизации уже есть, схема уже обкатана.
Пойду на новую ветку, почитаю.
Sasa
289 - 10.06.2002 - 09:02
А мне казалось что у мужичка с ИЖом и у мужичка с КАМАЗОМ будут и бизнес процессы другие...
Вот я не могу понять зачем малому предприятию - бюджетирование, планирование, прогнозирование, оперативное управление производством, запасами в полной ее мощи? С новой платформой приобретается как раз недоступная ранее функциональность.
2 All
290 - 10.06.2002 - 10:10
А слабо в 1С написать справочники на внешней компоненте????
2 All
291 - 10.06.2002 - 10:15
Что еще хотелось бы: табличная и шапочная часть документов. Кажись все. Хотя кто знает сильно ли тормозит в 1С журналы документов? Если да то хотелось бы еще и журналы документов....
Вот. Я не сильно размечтался?
ЗЫ: И чтоб это работало (ВК) на DCOM, т.е. на сервере!
SerBabah
292 - 10.06.2002 - 11:17
2(289, Sasa)
Зачем малому предприятию бюджетирование?
Чтобы выжить!
Малый бизнес более ограничен в ресурсах и более подвержен воздействию внешней среды.
Sasa
293 - 10.06.2002 - 13:34
Конечно ограничен - тем более он не сможет себе завести департамент бюджетного планирования:)
slw
294 - 10.06.2002 - 13:40
(293) А что такое малый бизнес с твоей точки зрения - $100К оборота в месяц это малый бизнес или нет? Так в такой конторе все начальники отделов, т.е. люди ответственные за расходы/доходы были построены и в начале месяца они выдавали свои планы в виде бюджетов.
ppson
295 - 10.06.2002 - 17:06
Ну что, сдох сабдж?