Учет сырья и нефтепродукции
Официальная постановка задачи была озвучена устно без всякой разработки технического задания: Поставить учет продукции на электронные рельсы в том виде, в котором сейчас работает предприятие. Это означало то, что предприятие и его директор создали свой специфический учет сырья и продукции, который в данной рыночной системе было жизнеспособно. Именно поэтому или в силу еще каких-либо обстоятельств было принято решение выполнить проект создания информационной учетной системы по образу и подобию того учета, который существовал в действительности.
Если сделать исторический экскурс и поискать решение учетных задач в прошлом, то скорее всего мы попадем в лавку старого еврея, торгующего керосином где-нибудь в районе Одессы. Кто знает как вел дела в своей лавке старый еврей? В лавке его было нечто, что позволяло учитывать товар, его приход и уход. Если в комнатке позади лавки работало небольшое производство, то это нечто учитывало приход сырья и реализацию продукции также хорошо без применения высокоскоростных компьютеров.
Это нечто было настолько простым и эффективным, что современные ERP системы со всеми их заумными изощрениями и проблемами сопровождения являются скорее шагом назад, чем вперед. А сам старый еврей, видимо, был умнее группы современных ERP внедренцев. Это нечто носило имя: Амбарная Книга.
Основой записей в амбарной книге являются величины, измеренные некоторым Способом Измерения. При анализе единиц измерения в СР я был просто поражен тем, что единицы измерения были разработаны неверно и стояли на последнем месте разработки. В дальнейшем пришлось переписать класс единиц измерения в СР. Аналогичным образом, были переписаны единицы измерения в «Питер Мобайл», организации по пошиву чехлов для телефонов, когда было организовано небольшое производство. Хочу сказать, что и в 1С да и в других системах единицы измерения стоят не на первом месте, поэтому являются атрибутом вторичным типа бантика у кошки на шее.
Небольшое отступление перед тем как начать проектировать.
Когда амбарная книга у вас под мышкой и вы знаете чем и как измеряет заказчик, можно начинать индивидуальный пошив информационной системы. Не сомневаюсь, что это многие пробовали сделать. Кто нибудь пробовал сшить костюм на верблюда? Ну, максимум на породистую лошадь можно. А вот на верблюда трудно – ГОРБы мешают. Именно поэтому разработчик спокойно смотрит в будущее, поскольку шьет информационные костюмы систем для организаций под заказ. А, в большинстве своем, все современные организации нарастили свой ГОРБ, который мешает им примерить современный костюм информационной системы из магазина. Тем более иностранного покроя. Стандартность покроя современной информационной системы приводит к тому, что продавец начинает нагибать покупателя, говоря, что его собственный ГОРБ – это атавизм, от которого надо избавляться. От очередного нагибания у покупателя возникает дополнительный ГОРБ, от которого тоже надо избавиться оперативно. И так до бесконечности.... Аллергия натертости от нового, но неудобного костюма заставляет резать по живому сложившуюся административную систему не только производства, но и моральных и гуманитарных ценностей.
ГОРБы существуют не только у организаций, но и у государств. Самый простой пример – это Бухгалтерия 1С, обеспечивающий правильный покрой фискального пальто для малого бизнеса государства Российского. Ну, а какой покрой пальто у Соединенных Штатов? Годится ли он для России? Или Европы? Штаты утверждают, что их покрой годится для всех национальных ГОРБов. Кто это видел? Видно обратное, любой с национальным ГОРБом, приобретший информационную систему, нагибается и получает еще один дополнительный ГОРБ. И здесь речь идет не о локализации, а о логике работы всей информационной системы в рамках организации.
Здесь речь о том, что создавший информационную систему под чейто заказ (ГОРБ), пытается ее продать еще раз кому-либо. И не важно, что second hand товар, сшитый на одногорбого верблюда, примеривается на двугорбого, или наоборот. Или рослый товар на малорослого. Зато дешево. Это называется по научному масштабируемостью. Но мина не в этом. Мина в том, что информационная система подменяет живое управление предприятием, предлагая новый набор инструкций к действию. Незаметно от глаз происходит смена логики управления. И надо либо искать собственную экологическую нишу в новой информационной структуре, либо тянуть два ГОРБа, либо закрываться. Тривиальный принцип решения: ГОРБатого могила исправит.
Как могила выполняет исправление ГОРБатого? Уже все слышали про. NET технологию. Все очень красиво: объекты, классы, бросил контрол на форму и приложение заработало. Но главный здесь мусорщик или garbage collector и управляемая память. Задача мусорщика удалять мусор из оперативной памяти. Он понимает p-code or intermediate language(IL) и работает одновременно и внутри вашего приложения. То есть, он может переместить в памяти объект класса вашего приложения и никто этого не заметит. В плане простой уборки мусора все хорошо. Вы считаете это мусором и мусорщик убирает это.
Но представьте, вы не считаете это мусором, а мусорщик считает. Скажем, все объекты стоимостью ниже $100000. Вы привыкли приходить к себе в дом? Стоимостью $99999. Приходите, а дома нет. Конечно не физически, а в БД (на бумаге). Кто оформлял дома, скажет, что это еще хуже, чем физический снос дома. Или фасад тот же, а внутри чтото изменилось. Скажем кровать прикручена к полу или доступ в туалет закрыт.
Или другой пример. Сделан итоговый отчет деятельности фирмы. Но алгоритм разноски по статьям затрат другой. Итоговые цифры отчета бьются по всем показателям. Однако будущие организационные, а может быть и стратегические решения, которые принимаются именно по статьям затрат, будут неверны. Это невозможно? XP уже написано на. NET. Crystal Report 9.2 – тоже. Многое уже переписывается. Мусорщик уже работает рядом с вами. В общем на. NET и суда нет.
Отступление. Любой интерпретатор является своего рода мусорщиком и вашим компаньоном, будь он Java machine or Basic or. NET. Безусловно интерпретирующий подход облегчает разработки, но к легкости разработок добавляются проблемы доверия к интерпретирующей среде и способность ее быть управляемой извне, но не вами.
Вот как раз в этом месте и нужен индивидуальный пошив информационной системы, обеспечивающий продолжение принципов руководства за рамки голов его. Аккуратный покрой костюма информационной системы, в соответствии с формой сложившегося ГОРБа организации. А также избавление от мусорщика, решившего управлять вашим предприятием вместе с вами.
NEXUS технология способна на индивидуальный пошив информационной системы без мусорщика. Это оперативный контур управления предприятием, способный начать работу в недоделанном виде сразу и завтра. Послезавтра система будет усложнена, но никогда уже не остановлена. Модификация происходит без остановки, на ходу. Усложнение может выполнять любой специалист, знающий только transactSQL, и знакомый с принципами объектно-ориентированного подхода.
