al1618давайте проще, вот "простенькая" для ИТ задача:
Необхоимо организовать учет отходов производства в разрезе:
1.Материала (лист - марка, толщина)
2.Цеха
2.Участка
3.Стелажа
4.МОЛ
6.Технологической карты из которой обрезок
7. Чертеж из которой обрезок
8. Производственного заказа (в случае индивидуального уникального производсва)
(добавить нужное на свое усмотрение :) )
Учитывать необходимо в ДВУХ единицах измерения - весе и "эффективной" площади
При этом ЛЮБОЙ мастер, начальник цеха и т.д. (т.е. человек владеющий машиной на уровне Эксель а не программирования в БД) должен смочь получить данные в нужном ему разрезе, по произвольному набору указанных признаков.

Например:
1.Получить ПОЛНЫЙ список чего висит на МОЛ (в случае увольнения, например) - с группировкой (порядок произвольный) по остальным признакам - цех, место хранения, материал, площадь, вес.
2. получить общую площадь по остаткам листа определенной марки/толщины в цеху (для подбора раскроя из остатков)- группировка "где лежит" - участок,стелаж, МОЛ
3. Получить "недорезанные" остатки по чертежу (вообще постоянный головняк производства) - группировка, чертеж, место хранения, площадь.
5.Отобрать общий вес "обрезков" площадью (или весом) "<" определенных марок стали (3пс например) для сдачи металлолома цехом и освобождения площадей хранения.
6. Отобрать все "остатки" определенного заказа по весу - контроль процента продвижения.
(добавить нужное на свое усмотрение :) )

Пример конкретный, но если металл поменять на яблоки или краску или детское питание - ничего кроме "ключей карточки учета" не изменится :)
В ИТ, такой учет настроить - мне 30 минут, 5 минут настроить и 25 - протестировать ничего ли не забыл :) , с созданием специфических документов - полдня. ("без внедрения изменений" естественно)

В любой другой системе - проще сбегать за веревкой и мылом :) , ну или рассказать что склад=МОЛ это "лучшая практика" :)
а знать остатка стоимость ТОЛЬКО в рамках завода - круче некуда :)

Не совсем понятно, как эта задача связана с темной сабжа... Ну да ладно.
Контрпример, еще более конкретный:

На нескольких установленных по соседству станках из латунного прутка вытачиваются разные болты разной длины, с разной резбой, с разной головкой и разного диаметра. В процессе вытачивания образуется латунная стужка, то есть, отходы, которые в последствии сдаются во металлолом. Стружка со станков падает на пол. Чернорабочий, работая метлой, заметает эту стружку в одну большую общую кучу, которая некоторое время лежит в цеху, а в последствии транспортируется во двор под пресс металлолома и складируется рядом для погрузки в грузовик и отправки во вторсырье.

Теперь несколько вопросов:

1. Как отделить в учете стружку, полученную при обработки прутка d8 мм от стружки, от полученной при обработке прутка d6 мм, если их невозможно отделить даже физически?

2. В каком цеху и на каком участке должен числиться брикет спрессованной стружки, если он получен из куч нескольких цехов и участков?

3. Кто является МОЛ спресованного брикета, лежащего возле пресса?

4. По какой технологической карте был получен брикет спресованной стружки, если их было несколько?

5. Как можно определить, по каким конкретно чертежам каких именно болтов были получены отдельные стружинки в спресованном брикете?

6. Как определить перечень производственных заказов, в которых были использованы болты, от производства которых получена прессованная стружка, если еще не известно, когда эти заказы поступят и сколько их будет, потому что болты производятся просто под статистическое пополнение запасов болтов?

7. Кто будет измерять эффективную площадь кучи, занимаемой стружкой, пока она лежит в цеху?

8. Кто будет взвешивать кучу стружки, лежащую в цеху и каким способом (то есть ДО ее прессовки и подготовки к отправке)?

К чему я это... Ах да, один "заумный пример" (но при этом очень конкретный), не имеющий никакого отношения к теме обсуждения против другого "заумного примера" (тоже конкретного, но уже немного менее конкретного), не имеющего отношения к теме обсуждения. Просто, чтобы потрясти воздух... :)

Коллеги, ей богу, вы меня поражаете... :) Я повалял дурака, и на это валяние дурака получил "мозговой штурм". :)

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

Дурака я валял, чтобы немного разрядить обстановку. Но когда порох взвешен в воздухе, пытаться что-либо разрядить опасно... :)

Так вот, коллеги, что хочу сказать по сабжу... Когда я впервые услышал об IT-Предприятии, первое и самое основное, на что я обратил внимание, это на то, что написана она на фокспро. Чтобы понять, почему, нужно сделать небольшое лирическое отсутпление, чтобы вы могли прочувствовать как бы "флюиды", которые на меня действовали. Я начал работать с фоксом еще в мохровую древность с самых первых версий под DOS. Я помню времена, когда фокс был одним из самых передовых продуктов. Он демонстрировал рекордную производительность, самые передовые методы построения индексов, в нем одном из первых появились SQL-запросы и "событийная ориентированность" когда остальные XBase только раскачивались... Потом я юзал клиппер, потому что он позволял создавать компилируемые приложения, потом фокспро уже под виндами... Вообще чего я только не юзал (разных алгоритмочиеских языков только десятка полтора), но фокс был какое-то время для меня доминантным инструментом... Потом я как-то плавно перебрался на MS Access, и среди сообщества аксессников многим был известен Garya наряду с Сергеем Новиковым и Андреем Митиным. Garya был одним из первопроходцев, который прошел по непаханному минному полю :) и продемонстрировал сообществу возможности только что появившегося ADO и ADP-приложений, а также привел длинный перечень выявленных глюков и нащупанные пути их обхода... Фокс остался где-то там, за спиной. За спиной осталось также уже давно написанная мной статья, позже продубливанная на множестве посвященных аксессу ресурсов, с названием "Некоторые соображения по поводу разработки крупных проектов на Access-97" (хочу обратить внимание на подчеркнутую часть фразы). ПМСМ, нет совершенно никакого смысла перечитывать сегодня содержание столь древних и по моим нынешним оценкам наивных скрижалей, поэтому не привожу ссылку. Важно понять, что фокс был уже позади, когда я начал всерьез задумываться над отличием технологий разработки крупных проектов от проектов не очень крупных. И когда я уже предпочитал MS Access фоксу, в самом начале этой статьи фигурировала вот такая мысль:
цитатаMS Access НЕ является подходящим инструментом для крупных проектов. Это первая и важная мысль, которую нужно "подумать" прежде чем браться за проект. MS Access - очень удобный и простой инструментарий для быстрой разработки НЕБОЛЬШИХ приложений для небольшого количества пользователей в самые короткие сроки.
Эта мысль вызвала тогда бурю протестов со стороны приверженцев аксесса, не важно какие там приводились аргументы сторонами, самые главные так и не были озвучены, когда статья уже безбожно устарела. Но и после значительного последующего усовершенствования аксесса и фокспро, появления ADO, WEB-страниц и всяких прочих наворотов я только всё больше и больше утверждался в своем мнении, особенно после того, как пощупал другие инструменты, которые больше годились для подобных целей.

Я поддерживал довольно плотные контакты с фокспрошниками, с некоторыми работал рядом. Но к тому моменту, когда я узнал об IT-Предприятии, для меня фокспро был уже не просто вчерашним, а чем-то позапозапозавчерашним. Я хорошо представлял возможности этого инструментария, знал многих, кто им пользовался в прежнее время и в нынешнее, знал возможности многих и многих прикладных решений, написанных на фокспро, и я ощущал некоторую особую ментальность, которая сложилась среди фокспрошников, да и среди аксессников, по правде говоря. Я ощущал что-то такое.... мммм... трудно объяснить.... В общем, какую-то истошную увлеченность изобретением велосипедов, если в двух словах. Я сам когда-то переболел такой увлеченностью, однозначно определился с их нишей, и как-то уже посматривал за горизонт, а не за спину. И вот я узнаю, что ИТ-Предприятие - это такая ERP-система, которая написана на фокспро. Попробуйте теперь понять то, что я тогда ощутил... :)

Ну, ощутил и забыл, делов-то... Мало ли у нас на Руси изобретателей велосипедов с астрономическим размахом... Но забыть совсем не получилось. Наш бизнес собирался приобретать завод на Украине, на котором происходило внедрение IT-Предприятия. Меня направили туда на ИТ-разведку. И тогда мне пришлось познакомиться с этим продуктом уже более плотно. Позже я встречался с представителями руководства ИТ-предприятия, мы обсуждали детали... И, не знаю, поверите вы или нет, но я был действительно очень и очень впечатлен.

Каким образом можно было, выстрелив из рогатки, подстрелить луну, в мою голову это как-то совершенно не укладывалось. Да, была груда глюков и недоработок, да поля со смешными названиями (это вообще традиционный стиль подавляющего числа фокспрошников и аксесников), но то, что она могла, это уже было запредельно в моем понимании. А после встречи с представителями руководства я понял, что это люди совешенно другого склада, нежели подавляющее число фокспрошников, которые вытаращив глаза хватаются за отвертку и плоскогубцы, чтобы построить звездолет. Они прекрасно понимали, что инструмент уже устарел и уже работали над переводом системы на новую платформу, они глубоко понимали менеджмент производства, а не были ура-программистами, и вообще это были люди незаурядного ума. В ИТ-Предприятии я обнаружил массу изящнейших концептуальных идей. Качество их реализации - это отдельный вопрос, но само их наличие меня очень впечатлило. Мне никогда прежде не приходилось видеть кастомизируемых систем, написанных на фокспро, такого масштаба. Жесткие - да, видел, но кастомизируемые - нет. Поэтому в моем представлении ее разработчики выжали из фокса больше, чем из него можно было выжать. И я, если говорить откровенно, ими восхищаюсь. У них не было такой команды, которая работала над SAP и они не использовали достаточно продвинутые инструментарии, поэтому проблемы были неизбежны. Но то, что они все-таки сделали, в моем понимании это был просто полный атас. Они выжали воду из камня. Поэтому у меня никогда не повернется язык сказать о них хоть половинку недоброго слова. Это достойно уважения, по крайней мере, с моей стороны.

Инструментарий этот да, глючен, местами серьезно недоработан... Но это крупная система, действительно крупная система. Сделанная с использованием старых технологий. Ее сравнивают с тем, что сделано с применением других технологий, более современных. Конечно же, где-то и в чем-то она неизбежно им проиграет. Но у меня язык не поворачивается ее хаять. Потому что это самый настоящий шедевр, если смотреть на него с точки зрения искусства.

Если смотреть с точки зрения потребностей клиента, то тут уже всё не так однозначно. Это система типа "расческа" (термин когда-то был придуман мной). Если нарисовать график возможностей в привязке к потребностям конкретного предприятия, которое только собирается начать его внедрять, то мы увидим резкие пики (какая-то функциональность хороша и даже черезмерно) и не менее резкие провалы (простейшие вещи, которые вдруг кому-то понадобились, совершенно никак невозможно реализовать). Вероятно, существуют предприятия, потребности которых сразу же совпали со всеми пиками, и провалы остались практически незамеченными. Но я не думаю, что их много. Я полагаю, что ИТ-Предприятие идет сейчас неравный бой с провалами на тех предприятиях, где они не просто заметны, а где в них всё уперлось. Возможно, какие-то из них удается успешно ликвидировать. Но они настолько глубоки, что быстро это сделать наврядли возможно.

В общем-то, система, ПМСМ, вполне достойная, чтобы конкурировать, например, с 1С:УПП. По крайней мере, некоторые зубки "расчески" выдаются так далеко, что УПП где-то там далеко внизу почти не видно. И возможно эти зубки кому-то очень-очень нужны. Правда, у УПП нет такого частокола и глубоких провалов... В общем, если брать "среднебольничую" оценку, то "средняя ценность" УПП, ПМСМ , примерно на том же уровне, на котором средняя ценность ИТ-Предприятия. А вот сбалансированность достоинств и недостатков совершенно разная. У IT-предприятия потрясающие достоинства и не менее потрясающие недостатки. У УПП нет потрясающих достоинств, но нет и потрясающих недостатков. Поэтому УПП внедрять как бы менее рисковано - меньше шансов нарваться на полно-абзацный провал. Я сравниваю эти системы потому, что они обе "родом из СНГ", и это важно - сравнивать сравнимое. Что у нас там еще родом из СНГ? Галактика? Уффф... Вот тут мне сравнивать труднее. Скажу лишь, что лично мне Галактика меньше нравится, чем ИТ-Предприятие. По крайней мере, когда речь идет о построении учета именно на производственном предприятии с высокой степенью детализации, ПМСМ, Галактика спасует перед ИТ-Предприятием. Хотя, для госбюджетных учреждений Галактика, скорее всего, и больше "отшлифована". Примерно такая же картина с Парусом. Но, повторяю, это мой сугубо субъекутивный субъективизм. В детали мне, често говоря, вдаваться бы не хотелось. И вообще, система, ПМСМ, далеко не самое главное. Есть масса других очень важных вопросов, которые не относятся непосредственно к системе как таковой.

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

Что еще? Насколько я понимаю, есть некоторые проблемы в аккумулировании требований множества предприятий-заказчиков в некий обобщенный функционал. У каждого заказчика возникает что-то вроде уникальной версии ПО, а не кастомизированная универсальная система. ПМСМ, имеются проблемы с управлением изменениями, с выпуском новых версий и релизов. Это, кстати, основная причина, по которой в ИТ-Предприятии толпа людей рвется на части. Многие пытаются сделать еще раз, но немного по-другому то, что уже сделали другие. То есть, выполняют сизифову работу. И тут, ПМСМ, проблема в том, что руководство ИТ-Предприятия, хорошо разбирающееся в производственном менеджменте, ПМСМ, немного недостаточно ориентируется в ИТ-менеджменте, например, в ITIL.

bahrovGarya,

А на вашем заводе чем закончилось внедрение этой программы?Нет, оно было прервано. Но нельзя сказать, что в этом виновато именно IT-Предприятие. Внедрение стартовало еще до включения завода в холдинг. Потом произошли серьезные изменения в структуре управления заводом, тяжелая экономическая ситуация привела к необходимости заморозить финансирования проекта. Именно в этот период я и выезжал на завод. Когда завод был включен в холдинг, была попытка сдвинуться с мертвой точки, но не было "локомотива" который бы взялся за этот проект. Я был слишком занят, чтобы всерьез за него браться, обходился только беглой оценкой и выдачей рекомендаций руководству холдинга. Холдинг только ообразовался, ИТ-подразделение было слишком маленьким, чтобы оно могло справиться со всем ворохом задач... Так что на 95% вина за пробуксовывание проекта лежала на заказчике.

Руководство холдинга приняло решение выходить на IPO на зарубежную площадку. И это повлияло на многие решения, в том числе на проект внедрения ERP на этом заводе. По политическим соображениям было принято решение внедрять на заводах ERP-системы, названия которых хорошо известны потенциальным зарубежным инвесторам. Проект был полностью прекращен и вместо ИТ-Предприятия был запущен проект по внедрению BAAN, уже на достаточно серьезном уровне, с необходимыми ресурсами, с серьезной концентрацией внимания руководства холдинга на этом проекте, с выделением грамотных ИТ-руководителей, имеющих достаточный административный потенциал и рычаги воздействия... Если бы с аналогичным настроем взялись за проект по внедрению ИТ-Предприятия, то и с ним бы все пошло в гору и успешно бы завершилось.

Андрей Ж.,

ПМСМ, очень важно, каким способом производится кастомизация. Я полагаю, что методы, которые использует разработчик для получения новых версий и релизов универсального кастоимзируемого на местах функционала (назовем его для кратости "универсалом") не пересекались и не вступали в конфликт с методами, которые используются для кастомизации на местах для привязки "универсала" к конкретной местности. Нужно не забывать, что ничего в природе не существует постоянного. Изменения, которые производятся по совершенно разным причинам совершенно разными людьми (которые несут ответственность за их качество!) не должны портить те процессы, которые связаны с изменениями, производимыми другими людьми для других целей и со своей собственной сферой ответственности. К сожалению, эту мысль недостаточно глубоко воспринимают очень многие фокспрошники, аксесники, одинэсники и вообще очень и очень многие айтишники самого разного профиля и "технологической ориентации" (не все, конечно, но подавляющее большинство, образуя при этом особое такое флюидное облако искаженной ментальности).

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

Когда речь идет о крупных системах, используемых в промышленных масштабах множествами предприятиями, инструментарий управления изменениями должен по возможности обеспечивать автономность и независимость изменений "универсала" от измений кастомизируемой части. Изменение "универсала" лично в моем понимании - это вообще не кастомизация. Эту мысль не додоумали ни в ИТ-Предприятии, ни в 1С (два конкурента, которые я тут сравнивал). Но если для 1С грамотная (я бы даже сказал "гениальная") маркетинговая политика позволяет ее как-то компенсировать, то для ИТ-Предприятия, не использующих никаких особо выдающихся маркетинговых компенсаторов данной проблемы, эта проблема становится ключевой для бизнеса этого вендора. Впрочем, для многих других систем она тоже имеет место, просто выражена в разной степени.

Андрей Ж.хотя бы на одном предприятии холдинга, где Вы работаете что-нибудь 100% внедрено?Разумеется. Baan на том предприятии, о котором я говорил, запущен в работу. Но лично мне больше нравится реализация SyteLine, произведенная на другом заводе. Вообще-то, я как бы не очень уверен, что имею право об этом говорить, поэтому мне не хотелось бы развивать эту тему. К тому же, это может быть воспринято и как реклама, и как оффтоп в данном треде.

al1618А вот вопрос с "гребенкой" интересен жутко - может подскажете пару провалов...al1618, я очень опасаюсь, что если их озвучу, начнется новый виток напряженности, чего бы мне очень не хотелось. Наверняка многие из тех "провалов", которые я наблюдал, уже ликвидированы, потому что времени с тех пор уже прилично прошло. Я предлагаю относиться к сказанному мной как моему сугубо субьективному ощущению без каких-либо претензий на объективность. Ок? :)

Андрей Ж
Есть системы с поддержкой "слоев". Это одно из технологических решений, которое позволяет наиболее приблизиться к обеспечению взаимной независимости процессов управления изменениями. Я вполне допускаю иные варианты (кроме слоев), например, использующие идеи SOA. Либо комбинацию того и другого. Может быть множество других методов борьбы с озвученной мной проблемой. Которые лучше существенно лучше ее решают, чем перечисленные Вами пункты. Только один из перечисленных Вами пунктов может быть использован для ее решения - первый. И только в том случае, если разработчик производит поставку ТОЛЬКО платформы и не занимается поставкой решений на этой платформе. Каждое решение - это своего рода "кастомизация платформы". Но это очень куцое решение (надеюсь, Вы это понимаете). Второй и третий пункты направлены не на решение этой проблемы, а на ее создание.

Представьте себе разработчика, у которого купило систему 1000 заказчиков. У каждого из заказчиков масса нюансов собственной кастомизации. Что у себя имеет разработчик? 1000 версий одной системы? Как он намерен вносить в них изменения? Допустим, он внес ровно одно измение во все сразу. Сколько новых релизов получилось? Опять 1000? Представляете себе тестирование 1000 новых релизов после одного внесенного изменения? Допустим, он пытается объединить в среднем 500 изменений у каждого из 1000 заказчиков в какой-то совокупный пакет изменений. Посмотрите, какая интересная получается картина. Общее число изменениий 500 * 1000 = 500'000 - на самом деле не самое пугающее число. Самое пугающее возникает тогда, когда мы вспоминаем, что их нужно "привести к общему знаменателю", уменьшив до числа не намного больше 500. Для этого необходимо проанализировать декартово произведение 1000 множеств из 500 элементов на непротиворечивость и по каждому факту обнаружения противоречивости найти устраняющее противоречие решение. Представляете себе объем работы, который должен проделать разработчик?

Теперь представим, что разработчик постарался снять с себя эту головную боль примерно так, как это сделала 1С. Что у разработчика имеется сейчас одна "типовая конфигурация". 1000 кастомизаций приводит к появлению 1000 "нетиповых конфигураций" у 1000 заказчиков, причем каждый кастомизатор произвел в среднем 500 изменений "типовой конфигурации" в процессе своей кастомизации. Разработчик выпускает первое изменение своей "типовой конфигурации". Но просто взять и наложить эти измения на 1000 кастомизированных - нельзя. Нужно сначала проанализировать появление возможных конфликтов наложения. Кастомизаторы у всех 1000 заказчиков должны открыть свои журналы регистрации своих изменений для целей кастомизации и соотнести каждое ранее выполненное кастомизационное изменение с каждым изменением, которое произошло в поставленном разработчиком новом релизе разработчика. Если новый релиз упаковывает 100 изменений разработчика, то нехитрый математический расчет позволяет определить, что каждый отдельно взятый кастомизатор должен проанализировать 100 * 500 = 50'000 комбинаций изменений, пропустив предварительно через свой мозг все изменения разработчика, а также восстановив в памяти все свои собственные изменения. Итак, 1000 кастомизаторов должны выполнить 50'000 комбинаций мозгового напряжения, а также найти решения по устранению конфликтов наложения чужих изменений на свои собственные. За счет исходящего из такого количества ушей дыма и наступает эффект "глобального потепления" на нашей планете (пока только я догадался, кто на самом деле его создал :) - шутка, на всякий).

Это обыкновенная математика, а точнее, комбинаторика. Существуюет масса задач в области ИТ, в которых задачи одной вычислительной сложности необходимо свести к задачам другой математической сложности (в алгоритмах сортировки, поиска, оптимизирующих алгоритмах решения задачи коммивояжера и т.д. и т.п.). Тут, ПМСМ, случай аналогичный. Просто нужно уйти от "тупого комбинирования" всех возможных комбинаций, не важно на чьей территории такое комбинирование производится - разработчика, заказчика или кастомизатора. Если изменения у них независимы , то математическая сложность решения выражается не произведениями и, тем более, не факториалами, а простой суммой. СУММОЙ! Как Вы полагаете, стоит решение такой задачи в масштабах всех ИТ-систем и технологий некоторого напряжения сил, чтобы апослее уже не так напрягаться и, тем самым, избежать глобального потепления? :)