Такой "спрос" в СССР не организовали. А вы пишете - "можно"...
В любом изменении процесса важно обеспечить три фактора - воля (лицо, которое будет изменение продвигать, и это будет являться внутренним интересом этого лица, вне зависимости от денег), поддержка руководства (в том числе ресурсная), и контроль (ежедневный, как только совершена ошибка - ее необходимо обнаруживать и выполнять корректирующие мероприятия).
Вы видите тут способ обеспечить эти три фактора? Чего-то не хватает, верно? Ещё нет структуры институтов управления, чтобы это обеспечивать. Создашь контрольный орган - он захлебнется (у нас-то - захлебывается, даже однозначного понимания норм нет у специалистов). Поддержка руководства - только до момента, пока большие организации не завопят "нам строить надо! План сорвем!". Ну и воля, стало быть, испарится.
Поэтому надо думать, Юрий Николаевич, надо думать.
По поводу идём дальше - этим и занимаемся. С переменным, как известно участникам рынка, успехом.
Насчёт КСИ не стоит, мне кажется. Они изначально страдали некоторой избыточностью, а теперь известные события резко ограничили ПО, с помощью которого это можно применять. ПО, скажем мягко, с ограничениями. Пока. Актуальным этот вопрос станет, наверное, лет через 10-15. Когда снимется фактор "у нас для вас нет других поэтов" и "зачем вам 3Д, вам нужны чертежи на стройку, давайте 3Д потом нарисуем".
Я бы лучше сначала описал текущую ситуацию и остановился на ключевых вопросах. Очень важно зафиксировать проблему. А дальше уже можно фантазировать.
Программы правильные, интересные. Но. Зачем они нужны? Как их использовать? Не будет ли это, как в известном анекдоте от Жириновского, тремя унитазами?
В СССР выстраивали единую систему проектирования, конструирования и строительства. Если вы берётесь за какой-то кусочек - нужно иметь полное представление обо всем процессе, иначе усилия будут бесполезны. Я пока не увидел, как вы предполагаете применять эти программы, или как будет выстроена система контроля терминологии.
Приведу простой пример. Проектировщик использовал при проектировании некое наименование МТР с ТУ. Специалисты заказчика ему сообщили, что нужно внести правки. Он исправил и указал в спецификации наименование, позволяющее приобрести на эту позицию один из 5 вариантов, существующих на рынке. Это - первый, базовый, вариант.
Второй вариант системы. Проектировщик получил на вход типовые технические требования. В них написано, какие ограничения на наименования у заказчика существуют. Немного пофантазировав, он добавил в наименование пару уточнений. Специалисты заказчика ему сообщили, что нужно внести правки и привести а соответствие с ТТТ. Он исправил и указал наименование, позволяющее приобрести один из 3-х вариантов, технически удовлетворяющих заказчика.
В чем разница? Разница в том, что в первом случае никаких требований нет, рынок максимально открыт до той степени, которую допускают конкретные специалисты заказчика. Во втором случае рынок открыт частично, конкретные специалисты заказчика имеют влияние на рынок, но не полное, т.к. руководствуются требованиями. И есть ещё одно важное отличие. Когда разрабатываются такие ТТТ - фактически, накладываются ограничения на процесс проектирования. Ограничив то, из чего можно проектировать, вы ограничиваете набор возможных решений. Это и есть комплексный подход, о котором я писал.
Я не вполне понимаю, каким образом указанные вами программные продукты закрывают потребности первого или второго варианта. Ну, сидят специалисты в управлении НСИ. Ну, есть у них база. И что? Чем они с этой базой помогут процессу? Та же нефтяная труба будет в этой базе отсутствовать на 40%, т.к. под каждый трубопровод выполняется отдельный расчет...
Второй вариант пробовали реализовать в СССР. Но столкнулись с проблемой - несмотря на плановый в целом характер экономики, в частности заводы все равно видели свой рынок. А каждый крупный заказчик был заинтересован в своей системе проектирования, ориентированной на свои условия строительства. У кого-то нет вечной мерзлоты, кого-то не интересуют бетонные основания и требования к вязкости стали. Поэтому проблема не в недостаточной формализации, проблема в диалектическом единстве рынка и плана. Отсюда и происходят обычаи, о которых вы написали.
Я уверен, что разработать единые правила наименований МТР возможно, но спроса на их использование пока не будет. Это как КСИ с более чем 20-ю классификаторами, из которых в реальной жизни нужно 2-3. Я прочитал статью и не уловил в ней понимания этого.
Хорошо, мы с вами согласились в том, что проблема не решается примитивной автоматизацией. Рад, что статья об этом, а не о том, что в СССР были самые правильные в мире наименования МТР. Однако дальше всё-таки есть два вопроса:
1) Не считаете ли вы, что частичная автоматизация всё-таки возможна? Она не исключит необходимости наличия специалистов, но не сократит ли это их необходимое количество и, что интереснее, запасы?
2) Не считаете ли вы, что проблема наименований несколько более комплексная, чем только МТО? Закроют ли ее введённые в штат специалисты по "техэкспертизе и терминологическому контролю", или только увеличат время согласования?
Вместе с остальными участниками отмечу актуальность статьи и погруженность автора (да, остатки представляют серьезнейший интерес, суммы называть не стану).
Но ни с логикой, ни с выводами я не согласен.
Первое, на что я обратил внимание - это отстутствие указания на смысл наименования МТР. А смыслов этих целых три:
Проектное описание МТР. Отражает функциональные характеристики МТР, необходимые в данной конкретной позиции. Например, коррозионная стойкость к СО2 (труба).
Конструкционное описание МТР. Отражает конструкционные характеристики. МТР еще не произведен, но известно, что сталь 13хфа. Или будет внутреннее трехслойное полиэтиленовое покрытие.
Фактическое описание МТР. Его на самом деле не формируют, но важно понимать, что есть паспорт, в котором по результатам испытаний могут написать, что покрытие устойчиво в течение 30 суток при соответствующих условиях.
Второе - как именно эти наименования используются. А именно:
Сопоставление проектного и конструкционного описания МТР для выявления возможности покрытия потребности.
Сопоставление конструкционных описаний МТР для выявления возможности замены.
Аналитические задачи (запасы, рынок).
Чтобы выполнить любую из задач, нужно иметь документ, в котором описания определены и формализованы (ТУ, ГОСТ, ТТТ заказчика). Дополнительно напомню про неполноту этих наименований, к ним нередко прилагаются ОЛ и ТТ.
Итого, если мы имеем такие описания и ОЛ - как мы можем решить задачи использования наименования МТР? Ответ - окончательной автоматизации эти задачи не подлежат. В частности, из-за того,что за наименованием скрывается документ, в котором определен, в числе прочего, порядок испытаний. При этом у заказчика он может быть один, у поставщика - другой.
В СССР, к которому взывает автор, была выполнена лишь попытка свести воедино процесс проектирования и результаты производства. В каких-то отношениях получилось, но есть, как известно, ГОСТы, разработанные на заводах. Так что без человека пока никак. Ну, есть у нас ТТТ. Ну, заставляем применять проектировщика и поставщика - пишем требования. Результат получаем с известным сопротивлением. Но его нужно все равно проверять. А если заказчик не мы? Тогда проектировщик и поставщик получают дополнительный... объем забот.
Так что, зло, наверное, немного не там, где обозначено. Не важно, как написать - "шуба норка" или "норковая шуба", или "шуба материал_верха:норка подклад:играющий". Важно, что с "верхняя одежда для услады глаз любимой жены зимой" это ни по ГОСТ, ни по ИСО сопоставить нельзя без дополнительного человеческого анализа.
Тема в том, что ИТ и автоматизация окончательно (но, надеюсь, не бесповоротно) разделились. Мы живём в абсурде. Ноша сия велика есть, и хорошо, что программисты это приблизительно понимают (пусть и не до конца).
Вы могли сделать только одно — отказаться работать в этой программе. Если, однако, даже с такими ограничениями для вас получался полезный результат — грех жаловаться. Если полезный результат был у других пользователей, а у вас дополнительные затраты — жаловаться тоже, в общем, грех, но попросить дополнительные ресурсы имело смысл.
Вместе с тем, тему повсеместного наплевательства на нужды исполнителей считаю раскрытой.
Я думаю, вам стоит поменять свою стратегию — те, кто ни… чего не понимают в автоматизации, ее возможностях и ограничениях, никогда не поставят вам задачу. Надо разобраться в том, что есть бизнес, и понять, что полезного для бизнеса вы можете сделать.
Темаинтереснаяно. Для неспециалиста (а изложены, отмечу, общие теоретические основания, т.е. в целях обучения) недостаточно подробно. На фразе "… можно представить матрицу А в виде произведения трех других..." я потерял нить. Что это за матрицы такие? U было, но не матрица, а множество; V и Е (кто его знает, как знак суммы добавить — подскажите) — раньше не упоминались… Было бы неплохо еще что-нибудь на эту тему написать.
Да все просто, на самом деле. Хорошего «рукля» трудно соблазнить даже очень хорошему «продавану». Вера его — не женская по принципу «так ведь хочется», а от слова «проверять». Вот как-то так :-)
«Не все хотят ровно сидеть на попе» — тем и живем. И, кстати, основную массу тех, кто хочет, я склонен считать также полезными членами общества — они, по крайней мере, не будут возражать против изменений, если изменения войдут в культуру предприятия. Они будут стабилизировать любую культуру. Есть, однако, «неолуддиты» (они же упомянутые «гондурасы»). Так вот у них, как раз, однозначно есть рукль, который им разрешает быть «гондурасами». И этот начальник — или тоже «гондурас», или сочувствующий, или просто дур не соответствует должности. Вот он и виноват.
По хорошим руклям согласен, но не стоит связывать хорошие качества рукля с приемлемостью им автоматизации. Он может передумать, когда увидит пользу или поймет, что этого не избежать. Но для этого он должен понять, что вы правы (а это не всегда очевидно даже вам) и должен верить в ваш опыт (а в это не всегда верите вы).
Но все же — что такое «линейный персонал»? Если это — «кассиры, продавцы, рабочие, учителя, врачи, агенты страхования, менеджеры по продажам, операторы, строители, консультанты, официанты, банковские клерки и прочее», то склонен не согласиться с вами при всем уважении. На мой взгляд (подчеркну, чтобы срач не разводить), их вина только в том, что они хотят «сидеть на попе ровно» (слышал однажды такое выражение), они только стабилизируют болото. А вот источником процесса заболачивания являются их руководители. У них есть все полномочия, чтобы изменить процесс, но они ими не пользуются. Хотя это их обязанность.
1) Согласен. Более того, если предприятие приучено к этой мысли — у него есть шанс удержаться при любых внешних условиях.
2) И тут согласен. Хотя пересмотра исключать не стоит.
3) Вот тут… не знаю… опыта пока, наверное, мало… но если внешние изменения не касаются — можно и закончить. Пока не касаются.
Батенька, как вы наивны… «гондурасов» коллеги никогда не пошлют, это ведь себе дороже, потому что у «гондураса» есть начальник, который, скорее всего, тоже «гондурас», ну или хотя бы сочувствующий… Все «сложные отчеты» — это не более как повод повосхищаться и больше никогда, НИКОГДА(!!!) эту кнопку (!!!) НЕ НАЖИМАТЬ (!!!). Потому как все хотят, назовем это так, работать (хотя, кого я обманываю, не работать, а просиживать штанцы или юбки). И чем меньше за ту же зп — тем лучше. Вы просто не учитываете того, что чем дольше выполняется поручение — тем значительней оно по своей важности. И никто никогда вам не расскажет нюансов того, как оно выполняется, чтобы вы, не дай Бог, не автоматизировали его.
Работает только одно — если руководство поддерживает, то нужно воздействовать на начальников означенных «гондурасов». Сначала — в личной беседе (тут обнаруживается разделение на «хитро-тупых» и просто «тупых»; договориться возможно, по моему опыту, в 10% случаев, не более), а потом — на ковер. Ну и, как вы понимаете, из-за этого возможны эксцессы. Если вы недостаточно разобрались в том, как работает предприятие, если вы не можете ответить на вопрос «что мне делать, чтобы отразить эту ситуацию в системе?» — это ваш личный риск вылететь к чертовой бабушке с волчьим билетом.
опа, а ведь 14-й год, однако… извините, просто задело…
С одной стороны, как «ИТ-шник», не могу не согласиться. С другой стороны, как «ИТ-шник», не согласен. Если рассматривать ИТ как ИНФОРМАЦИОННЫЕ технологии, то — все верно, именно «ИТ-шник» должен отвечать за информационный обмен в организации. Но если рассматривать вопрос по существу — я только в одной организации видел, чтобы служба ИТ занималась хотя бы экспертной поддержкой в области информационного обмена. В остальных организациях за это отвечали все, кто осуществлял информационный обмен, а главным безответственным лицом (потому как очень трудно отвечать за то, чем, по сути, не владеешь и чего, как правило, не умеешь, да и просто некогда) был Главный Инженер.
Поэтому — несмотря на «системноссь мышленья» отдельных лиц, без желания, поддержки и адекватности руководства такие дела не сдвигаются. Если руководству оно не надо — все, кому оно тоже не надо, ничего делать не будут, т.к. даже если и приказ есть, по попе все равно не нахлопают, можно просто сидеть и хихикать на техучебе, отпуская остроумные замечания на тему «а если Ванечка ушел в отпуск — тогда как?».
Если говорить честно, получился пока не MS Project, но по интерфейсу теперь можно сделать что-то близкое к нему :-) А вот по логике работы — можно сделать нечто гораздо более подходящее к жизни.
Я скажу больше — все зависит от внутренней культуры компании и от того, куда ее ведут. Вы совершенно правы в том, что административные методы редко приводят к идеальному результату. В таком случае ГИ практически всегда назначают «самодуром». Но в случае, когда задачи ставятся, но не выполняются, выход только один — все-таки ввести учет.
Из-за чего задачи не выполняются — это, действительно, другой вопрос. Тут поможет анализ накопленных данных. Может получиться так, что причина — бешеная загрузка. Может — просто «тихий саботаж». Может — еще что-то. И в каждом случае рецепт исправления — свой, но в основе возможности анализа — учет. Наша задача — предоставить соответствующий инструмент. С возможностью его развития в любую сторону.
Честно сказать, писал и многоэтажные формулы. И даже сам кое-что выводил на их основе. И даже не только выводил. Будь у меня необходимая математическая база («методичка» :-)) — разобрался бы, не сомневаюсь. Заодно поправил бы пару ошибок :-) (буду честным, пару других все равно не заметил бы).
Но вижу — у вас есть некий конфликт в части интеллектуальной собственности. Наверное, вы смогли заставить работать либу нетрадиционным методом (который описали). Возможно, без участия автора. Автора, возможно, это возмущает. В этом смысле сочувствую всем участникам. И вам, будь вы даже чрезмерно экономными на взгляд автора. И автору, будь он даже чрезмерно амбициозным на ваш взгляд. А больше всего — пользователю. Потому, что это он будет ловить проблемы этой либы без надежды, что проблемы когда-нибудь можно будет устранить.
Такой "спрос" в СССР не организовали. А вы пишете - "можно"...
В любом изменении процесса важно обеспечить три фактора - воля (лицо, которое будет изменение продвигать, и это будет являться внутренним интересом этого лица, вне зависимости от денег), поддержка руководства (в том числе ресурсная), и контроль (ежедневный, как только совершена ошибка - ее необходимо обнаруживать и выполнять корректирующие мероприятия).
Вы видите тут способ обеспечить эти три фактора? Чего-то не хватает, верно? Ещё нет структуры институтов управления, чтобы это обеспечивать. Создашь контрольный орган - он захлебнется (у нас-то - захлебывается, даже однозначного понимания норм нет у специалистов). Поддержка руководства - только до момента, пока большие организации не завопят "нам строить надо! План сорвем!". Ну и воля, стало быть, испарится.
Поэтому надо думать, Юрий Николаевич, надо думать.
По поводу идём дальше - этим и занимаемся. С переменным, как известно участникам рынка, успехом.
Насчёт КСИ не стоит, мне кажется. Они изначально страдали некоторой избыточностью, а теперь известные события резко ограничили ПО, с помощью которого это можно применять. ПО, скажем мягко, с ограничениями. Пока. Актуальным этот вопрос станет, наверное, лет через 10-15. Когда снимется фактор "у нас для вас нет других поэтов" и "зачем вам 3Д, вам нужны чертежи на стройку, давайте 3Д потом нарисуем".
Я бы лучше сначала описал текущую ситуацию и остановился на ключевых вопросах. Очень важно зафиксировать проблему. А дальше уже можно фантазировать.
Программы правильные, интересные. Но. Зачем они нужны? Как их использовать? Не будет ли это, как в известном анекдоте от Жириновского, тремя унитазами?
В СССР выстраивали единую систему проектирования, конструирования и строительства. Если вы берётесь за какой-то кусочек - нужно иметь полное представление обо всем процессе, иначе усилия будут бесполезны. Я пока не увидел, как вы предполагаете применять эти программы, или как будет выстроена система контроля терминологии.
Приведу простой пример. Проектировщик использовал при проектировании некое наименование МТР с ТУ. Специалисты заказчика ему сообщили, что нужно внести правки. Он исправил и указал в спецификации наименование, позволяющее приобрести на эту позицию один из 5 вариантов, существующих на рынке. Это - первый, базовый, вариант.
Второй вариант системы. Проектировщик получил на вход типовые технические требования. В них написано, какие ограничения на наименования у заказчика существуют. Немного пофантазировав, он добавил в наименование пару уточнений. Специалисты заказчика ему сообщили, что нужно внести правки и привести а соответствие с ТТТ. Он исправил и указал наименование, позволяющее приобрести один из 3-х вариантов, технически удовлетворяющих заказчика.
В чем разница? Разница в том, что в первом случае никаких требований нет, рынок максимально открыт до той степени, которую допускают конкретные специалисты заказчика. Во втором случае рынок открыт частично, конкретные специалисты заказчика имеют влияние на рынок, но не полное, т.к. руководствуются требованиями. И есть ещё одно важное отличие. Когда разрабатываются такие ТТТ - фактически, накладываются ограничения на процесс проектирования. Ограничив то, из чего можно проектировать, вы ограничиваете набор возможных решений. Это и есть комплексный подход, о котором я писал.
Я не вполне понимаю, каким образом указанные вами программные продукты закрывают потребности первого или второго варианта. Ну, сидят специалисты в управлении НСИ. Ну, есть у них база. И что? Чем они с этой базой помогут процессу? Та же нефтяная труба будет в этой базе отсутствовать на 40%, т.к. под каждый трубопровод выполняется отдельный расчет...
Второй вариант пробовали реализовать в СССР. Но столкнулись с проблемой - несмотря на плановый в целом характер экономики, в частности заводы все равно видели свой рынок. А каждый крупный заказчик был заинтересован в своей системе проектирования, ориентированной на свои условия строительства. У кого-то нет вечной мерзлоты, кого-то не интересуют бетонные основания и требования к вязкости стали. Поэтому проблема не в недостаточной формализации, проблема в диалектическом единстве рынка и плана. Отсюда и происходят обычаи, о которых вы написали.
Я уверен, что разработать единые правила наименований МТР возможно, но спроса на их использование пока не будет. Это как КСИ с более чем 20-ю классификаторами, из которых в реальной жизни нужно 2-3. Я прочитал статью и не уловил в ней понимания этого.
Хорошо, мы с вами согласились в том, что проблема не решается примитивной автоматизацией. Рад, что статья об этом, а не о том, что в СССР были самые правильные в мире наименования МТР. Однако дальше всё-таки есть два вопроса:
1) Не считаете ли вы, что частичная автоматизация всё-таки возможна? Она не исключит необходимости наличия специалистов, но не сократит ли это их необходимое количество и, что интереснее, запасы?
2) Не считаете ли вы, что проблема наименований несколько более комплексная, чем только МТО? Закроют ли ее введённые в штат специалисты по "техэкспертизе и терминологическому контролю", или только увеличат время согласования?
Вместе с остальными участниками отмечу актуальность статьи и погруженность автора (да, остатки представляют серьезнейший интерес, суммы называть не стану).
Но ни с логикой, ни с выводами я не согласен.
Первое, на что я обратил внимание - это отстутствие указания на смысл наименования МТР. А смыслов этих целых три:
Проектное описание МТР. Отражает функциональные характеристики МТР, необходимые в данной конкретной позиции. Например, коррозионная стойкость к СО2 (труба).
Конструкционное описание МТР. Отражает конструкционные характеристики. МТР еще не произведен, но известно, что сталь 13хфа. Или будет внутреннее трехслойное полиэтиленовое покрытие.
Фактическое описание МТР. Его на самом деле не формируют, но важно понимать, что есть паспорт, в котором по результатам испытаний могут написать, что покрытие устойчиво в течение 30 суток при соответствующих условиях.
Второе - как именно эти наименования используются. А именно:
Сопоставление проектного и конструкционного описания МТР для выявления возможности покрытия потребности.
Сопоставление конструкционных описаний МТР для выявления возможности замены.
Аналитические задачи (запасы, рынок).
Чтобы выполнить любую из задач, нужно иметь документ, в котором описания определены и формализованы (ТУ, ГОСТ, ТТТ заказчика). Дополнительно напомню про неполноту этих наименований, к ним нередко прилагаются ОЛ и ТТ.
Итого, если мы имеем такие описания и ОЛ - как мы можем решить задачи использования наименования МТР? Ответ - окончательной автоматизации эти задачи не подлежат. В частности, из-за того,что за наименованием скрывается документ, в котором определен, в числе прочего, порядок испытаний. При этом у заказчика он может быть один, у поставщика - другой.
В СССР, к которому взывает автор, была выполнена лишь попытка свести воедино процесс проектирования и результаты производства. В каких-то отношениях получилось, но есть, как известно, ГОСТы, разработанные на заводах. Так что без человека пока никак. Ну, есть у нас ТТТ. Ну, заставляем применять проектировщика и поставщика - пишем требования. Результат получаем с известным сопротивлением. Но его нужно все равно проверять. А если заказчик не мы? Тогда проектировщик и поставщик получают дополнительный... объем забот.
Так что, зло, наверное, немного не там, где обозначено. Не важно, как написать - "шуба норка" или "норковая шуба", или "шуба материал_верха:норка подклад:играющий". Важно, что с "верхняя одежда для услады глаз любимой жены зимой" это ни по ГОСТ, ни по ИСО сопоставить нельзя без дополнительного человеческого анализа.
Вместе с тем, тему повсеместного наплевательства на нужды исполнителей считаю раскрытой.
дурне соответствует должности. Вот он и виноват.По хорошим руклям согласен, но не стоит связывать хорошие качества рукля с приемлемостью им автоматизации. Он может передумать, когда увидит пользу или поймет, что этого не избежать. Но для этого он должен понять, что вы правы (а это не всегда очевидно даже вам) и должен верить в ваш опыт (а в это не всегда верите вы).
Но все же — что такое «линейный персонал»? Если это — «кассиры, продавцы, рабочие, учителя, врачи, агенты страхования, менеджеры по продажам, операторы, строители, консультанты, официанты, банковские клерки и прочее», то склонен не согласиться с вами при всем уважении. На мой взгляд (подчеркну, чтобы срач не разводить), их вина только в том, что они хотят «сидеть на попе ровно» (слышал однажды такое выражение), они только стабилизируют болото. А вот источником процесса заболачивания являются их руководители. У них есть все полномочия, чтобы изменить процесс, но они ими не пользуются. Хотя это их обязанность.
2) И тут согласен. Хотя пересмотра исключать не стоит.
3) Вот тут… не знаю… опыта пока, наверное, мало… но если внешние изменения не касаются — можно и закончить. Пока не касаются.
Работает только одно — если руководство поддерживает, то нужно воздействовать на начальников означенных «гондурасов». Сначала — в личной беседе (тут обнаруживается разделение на «хитро-тупых» и просто «тупых»; договориться возможно, по моему опыту, в 10% случаев, не более), а потом — на ковер. Ну и, как вы понимаете, из-за этого возможны эксцессы. Если вы недостаточно разобрались в том, как работает предприятие, если вы не можете ответить на вопрос «что мне делать, чтобы отразить эту ситуацию в системе?» — это ваш личный риск вылететь к чертовой бабушке с волчьим билетом.
опа, а ведь 14-й год, однако… извините, просто задело…
Поэтому — несмотря на «системноссь мышленья» отдельных лиц, без желания, поддержки и адекватности руководства такие дела не сдвигаются. Если руководству оно не надо — все, кому оно тоже не надо, ничего делать не будут, т.к. даже если и приказ есть, по попе все равно не нахлопают, можно просто сидеть и хихикать на техучебе, отпуская остроумные замечания на тему «а если Ванечка ушел в отпуск — тогда как?».
Из-за чего задачи не выполняются — это, действительно, другой вопрос. Тут поможет анализ накопленных данных. Может получиться так, что причина — бешеная загрузка. Может — просто «тихий саботаж». Может — еще что-то. И в каждом случае рецепт исправления — свой, но в основе возможности анализа — учет. Наша задача — предоставить соответствующий инструмент. С возможностью его развития в любую сторону.
http://www.fireevacuation.ru/files/posobie_prikaz_404.pdf
Но вижу — у вас есть некий конфликт в части интеллектуальной собственности. Наверное, вы смогли заставить работать либу нетрадиционным методом (который описали). Возможно, без участия автора. Автора, возможно, это возмущает. В этом смысле сочувствую всем участникам. И вам, будь вы даже чрезмерно экономными на взгляд автора. И автору, будь он даже чрезмерно амбициозным на ваш взгляд. А больше всего — пользователю. Потому, что это он будет ловить проблемы этой либы без надежды, что проблемы когда-нибудь можно будет устранить.