Смешались в кучу кони, люди…
Учет простоев зло, но самый лучший показатель — это все равно простои, т.е. извините, календарное время за вычетом простоев.
Все простои делятся на «технические» (обусловленные отказами) и «технологические» (обусловленные производственными планами, эксплуатацией и т.п.). На основе «технических» простоев рассчитывается, к примеру, такой показатель надежности как «коэффициент готовности», и на повышение которого, в частности и применяется FMEA (FMECA), как и следует из его названия (Failure Mode and Effect Analysis). И странно слышать что мониторинг надежности оборудования приведет компанию в «болото».
А вот с другим видом простоев, «технологическим», все гораздо интереснее. На них может влиять как качество планирования производства, логистика, обеспечение сырьем и материалами, так и «работоспособность» персонала (в том числе и перерывы на чаи-перекуры). И вот тут, соглашусь, во весь рост встает вопрос мотивации и оценки качества труда, но никак не раньше. Мониторинг простоев, при его правильной организации, как раз и позволяет понять «узкие места», где оборудование не выполняет его основные функции, или, другими словами недополучает прибыль. Нет, если конечно связать оплату труда оператора станка с простоями оборудования, которые на данном предприятии возникают в основном из-за проблем, скажем с электроснабжением, — то это закончится не очень хорошо, но это проблема возникает не из-за того, что компания занимается учетом простоев, а из-за того что у кого-то из отдела управления персоналом некоторые проблемы с мыслительным процессом и причинно-следственными связями. Шурупы можно и молотком забивать, а потом удивляться, почему они ничего не держат, но это не значит что шурупы — зло.
Но самое интересное в выводах, «Коэффициент полезной работы – это время, когда оборудования работало с пользой». Простите, но если мы возьмем некий период времени, и вычтем из него все простои (как «технические», так и «технологические»), то мы и получим то время, которое «оборудования работало с пользой», которое зачастую также называют «коэффициентом технического использования». Так все-таки, надо считать простои, или нет? :)
Отдельный вопрос к оценкам «экономической эффективности». Это что, повышение производительности? Или снижение расходов?
На собственном примере могу сказать — да, есть такая прегнусная черта у пользователей, не читать что им пишут. Сидишь, кодишь, эксепшины все аккуратно описываешь, все для пользователя, туды его в качель, а потом диалоги вроде такого:
(П)ользователь: Аллё! Ваша программа ни(нецензурно) не работает…
(С)аппорт: В чем это выражается?
П: Ошибку какую-то постоянно выдает!
С: Отлично, какую?
П: Не знаю, не читал.
С: А зря… Запустите программу и повторите ваши действия…
П: Тоже самое, ошибка.
С: О!!! Прочитайте, что там написано.
П: А я уже закрыл.
С: (много нецензурной брани).
Причем все это с завидной регулярностью. Попытки приучить пользователя читать бесполезны. А скорости с которой закрываются окна с ошибками может позавидовать бывалый старкрафтер.
NHibernate тоже не умеет обновлять базу, но это и логично, с учетом того сколько различных СУБД он поддерживает.
Для Firebird/Interbase я делаю проще. Обновление состоит из 3-х этапов:
1. Генерится новая временная база.
2. При помощи библиотеки из IBExpert метаданные сравниваются с метаданными основной базы и генерируется скрипт обновления.
3. Скрипт запускается на основной базе.
Естественно не все изменения можно применить, особенно если сильно меняется ссылочная структура, так что менять надо очень вдумчиво и внимательно, хотя это не излишне на всех этапах.
Абсолютно согласен. Это как пример того что ORM — не панацея, как может показаться новичкам, впервые освоившим его.
Кроме того огромный плюс Hibernate — это возможность управлять структурой хранения данных и спокойно работать с ними напрямую. С ужасом вспоминаю Bold и ECO — то что они генерят, без поллитра не разобрать. И хранимок там уже не наваяешь.
Есть. NHibernate 1.2.1, о котором идет речь в статье, — это портированный джавовый Hibernate 2.1, Сейчас уже есть NHibernate 2 beta, который соответствует Hibernate 3.2. А последняя рабочая версия Hibernate — 3.3.0.0, т.е. сначала разрабатывается Java версия, и уже после этого все вкусности портируются под .NET.
Во всем остальном — различия только в синтаксисе ;).
NHibernate очень любит увлекаться кэшированием. В определенных задачах это конечно плюс, но иногда кроме диких тормозов это ничего не дает. Особенно при большом объеме данных и крупных выборках, которые регулярно встречаются при построении отчетов.
Иногда приходится скрипя зубами отвергать удобный функционал NHibernate и грузить огромные коллекции в память и работать с ними уже там.
Вобщем не забываем чистить кэш и оценивать количество запросов к базе которое ORM генерирует.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Учет простоев зло, но самый лучший показатель — это все равно простои, т.е. извините, календарное время за вычетом простоев.
Все простои делятся на «технические» (обусловленные отказами) и «технологические» (обусловленные производственными планами, эксплуатацией и т.п.). На основе «технических» простоев рассчитывается, к примеру, такой показатель надежности как «коэффициент готовности», и на повышение которого, в частности и применяется FMEA (FMECA), как и следует из его названия (Failure Mode and Effect Analysis). И странно слышать что мониторинг надежности оборудования приведет компанию в «болото».
А вот с другим видом простоев, «технологическим», все гораздо интереснее. На них может влиять как качество планирования производства, логистика, обеспечение сырьем и материалами, так и «работоспособность» персонала (в том числе и перерывы на чаи-перекуры). И вот тут, соглашусь, во весь рост встает вопрос мотивации и оценки качества труда, но никак не раньше. Мониторинг простоев, при его правильной организации, как раз и позволяет понять «узкие места», где оборудование не выполняет его основные функции, или, другими словами недополучает прибыль. Нет, если конечно связать оплату труда оператора станка с простоями оборудования, которые на данном предприятии возникают в основном из-за проблем, скажем с электроснабжением, — то это закончится не очень хорошо, но это проблема возникает не из-за того, что компания занимается учетом простоев, а из-за того что у кого-то из отдела управления персоналом некоторые проблемы с мыслительным процессом и причинно-следственными связями. Шурупы можно и молотком забивать, а потом удивляться, почему они ничего не держат, но это не значит что шурупы — зло.
Но самое интересное в выводах, «Коэффициент полезной работы – это время, когда оборудования работало с пользой». Простите, но если мы возьмем некий период времени, и вычтем из него все простои (как «технические», так и «технологические»), то мы и получим то время, которое «оборудования работало с пользой», которое зачастую также называют «коэффициентом технического использования». Так все-таки, надо считать простои, или нет? :)
Отдельный вопрос к оценкам «экономической эффективности». Это что, повышение производительности? Или снижение расходов?
(П)ользователь: Аллё! Ваша программа ни(нецензурно) не работает…
(С)аппорт: В чем это выражается?
П: Ошибку какую-то постоянно выдает!
С: Отлично, какую?
П: Не знаю, не читал.
С: А зря… Запустите программу и повторите ваши действия…
П: Тоже самое, ошибка.
С: О!!! Прочитайте, что там написано.
П: А я уже закрыл.
С: (много нецензурной брани).
Причем все это с завидной регулярностью. Попытки приучить пользователя читать бесполезны. А скорости с которой закрываются окна с ошибками может позавидовать бывалый старкрафтер.
Для Firebird/Interbase я делаю проще. Обновление состоит из 3-х этапов:
1. Генерится новая временная база.
2. При помощи библиотеки из IBExpert метаданные сравниваются с метаданными основной базы и генерируется скрипт обновления.
3. Скрипт запускается на основной базе.
Естественно не все изменения можно применить, особенно если сильно меняется ссылочная структура, так что менять надо очень вдумчиво и внимательно, хотя это не излишне на всех этапах.
Пример использования аттрибутов:
А за наводку на ActiveRecords — спасибо, покопаем.
Кроме того огромный плюс Hibernate — это возможность управлять структурой хранения данных и спокойно работать с ними напрямую. С ужасом вспоминаю Bold и ECO — то что они генерят, без поллитра не разобрать. И хранимок там уже не наваяешь.
habrahabr.ru/blogs/net/37984/#comment_899304
Во всем остальном — различия только в синтаксисе ;).
Иногда приходится скрипя зубами отвергать удобный функционал NHibernate и грузить огромные коллекции в память и работать с ними уже там.
Вобщем не забываем чистить кэш и оценивать количество запросов к базе которое ORM генерирует.