Infinity Creator69
- Как по Вашему, кому принадлежит Ваша система? Или спрошу проще если столяр сделал на Вашей фирме стул - может ли он идти и торговать им на базаре?

Это тема отдельной беседы. Потому что система эта моя ровно на 50%. Без компании, где я ее реализую, я никогда не смог бы ее создать. Просто потому что у меня здесь "тепличные" условия: свободный рабочий день, свободный доступ к любой информации и т.п. И мой шеф прекрасно понимает потенциал системы. И если из нее к концу этого года мне удастся создать коммерческий продукт, в его раскрутку будет вложено энное количество средств.Это на самом деле очень существенный нюанс. Если существует приказ на разработку Вами этой системы в рамках выполнения Вами служебных обязанностей, то Вы являетесь автором системы, но владельцем его и его является компания, в которой Вы работаете. Если в Вашей компании зубастый до денег менеджмент, то готовьтесь к судебным тяжбам, когда этот менеджмент сообразит, что компания сама может продавать этот продукт.

Infinity CreatorЯ уже писАл выше - система точится под судоходство, но судоходство - только прикладная задача, реализуемая в рамках этой системы. Она изначально создается как универсальный продукт с определенной идеологией, ориентированной на создание оперативного информационного поля компании. Это общие слова. Для того, чтобы говорить в стиле "она всё сможет", нужно понимать специфику совершенно других бизнес-процессов в совершенно других отраслях. И глубину задач, на котоую она готова "нырять", а на которую не готова. Или Вы полагаете, что для печи обжига Ваша программа сможет подобрать оптимальные партии и комбинации деталей, которые в ней должны совместно обжигаться (с учетом температуры обжига, формы деталей, их объема и планируемого времени подачи на участок), да еще с учетом запланированного выхода в отпуск рабочего, ослуживающего эту печь и плановых ремонтов и техобслуживания, запланированного поступления от поставщиков материалов, из которых эти детали изготваливаются и т.д. и т.п.? Если у Вас еще остались сомнения, попробуйте ответить честно, сможет ли Ваша система расчитать 3D-модель детали, необходимой для производства некоторого конечного продукта.

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

Насколько я понимаю, Ваш продукт не является универсальным. Универсальной является технология его разработки. Это существенно разные вещи. А с помощью технологии может быть создан совершенно другой продукт-самописка, совершенно другим программистом.

Если же я что-то не так понял, то поясните пожалуйста, чем обеспечивается универсальность именно ПРОДУКТА ?

Infinity CreatorМожно, только вкратце, и пока только про событийно-ориентированность.
Используется следующий принцип: каждое предприятие - это определенная структура в физическом мире, которая имеет в каждый момент времени определенную архитектуру (т.е. производственные активы, счета в банках, кассы, сотрудники, поставщики, клиенты, склады, заявки, выставленные счета и т.п.) и информационную составляющую (данные, описывающие текущую архитектуту предприятия).Значит, для холдинговых структур, объединяющих множество юрлиц, использующих единые унифицированные НСИ, Ваша разработка не подходит? А если подходит, то способны ли Вы учесть их различия (учетных политик, бизнес-процессов, а не только реквизитов)?
А как там обстоят дела с репликацией, если учет ведется на территориально обособленных площадках?

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

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

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

Третья проблема связана с тем, что кроме явных событий, так или иначе связанных с некими "происшествиями" во внешней среде, требуется реакция на "таймауты". Это, например, истечения срока платежа. Таймауты могут измеряться секундами и минутами (если речь идет о технологических/производственных операциях), а могут измеряться годами (если речь идет об истечении срока исковой давности). Что с ними делать? Вывешивать программные агенты или службу, которая будет отслеживать таймауты и генерить события? А если нарушится хронология? :)

Я придумал более изящное решение, построенное на концепции детерминированности учетного времени (отлдичающегося от "календарного", текущего времени). То есть, с отражением событий по всей оси учетного времени от минус до плюс бесконечности (в том числе далеко-далеко в будущем) с учетом всей той информации, которая на текущий момент введена в систему. Когда появляется новое событие, происходит анализ всего, что ранее было отражено, и некоторые действия в системе, ранее уже отраженны отменяются (вроде как "сторнируются"). Однако, такой подход имеет свои недостатки.

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

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

Советую о таких вещах заранее подумать, дабы не потратить зря свои силы.

Infinity CreatorИ не вижу ваще ничего порочного в идее объединения этих технологий, в одной из которых великолепно реализованы механизмы связей, а в другом - механизмы фильтрации информации.Я примерно представляю, как средствами OLTP можно реализовать OLAP. Основная прибавка скорости в OLAP возникает за счет хранения предвычисленных агрегатов. Для того чтобы их хранить непосредственно в БД OLTP, нужно привязать корректировку агрегатов к транзакции. Что делает саму транзакцию более "тяжеловесной". А если множество пользователей пытаются добавлять/изменять/удалять информацию, которая изменяет в транзакции один агрегат, юзвери начинают сильно мешать друг другу, потому что транзакции могут выполняться только последовательно (если мы намерены получить в хранимом агрегате не искаженную сумму).

Чем больше измерений в кубе, тем больше комбинаций хранимых агрегатов. Тем больше их объем. При увеличении числа измерений объем агрегатов, если их все дейсвтиетльно хранить , может на порядки превысить объем исходных данных, по которым такие агрегаты рассчитываются. А время выполнения транзакции, которая одновременно завязана на пересчет всех агрегатов, может увеличиться до состояния, когда 1С со своей "тормознутостью" может выглядеть просто как реактивный самолет.

В типовом функционале MS Analisys Services реализованы возможности и HOLAP, и ROLAP, и MOLAP. И есть возможность выбрать оптимум между объемом хранимых данных и быстродействием отчетов. Не понятно, зачем изобретать собственный OLAP. Врядли его удастся реализовать лучше, чем это сделала MS. Тем более, в одиночку...

Infinity CreatorТ.е. для работы с ситемой потребовалось бы обучение. Зная специфику компании это было неприемлемо.Я сам обучал пользователей ИНФИНа... За полчаса - аудиторов и финансистов основным приемам работы в нем с целью вытаскивания любой аналитической информации. Час тратил на обучение новых бухгалтеров, после чего они работали в системе полностью самостоятельно. Платное обучение в самом ИНФИНе в составе группы всем-всем премудростям происходит за 2 дня. Обучать группу всегда существенно дольше (нужно объяснять, почему?).

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

Infinity CreatorНо забавно то, что я внимательно вчитался в задачу про плавильную печь и да, система смогла бы решить эту задачу.Вы это серьезно??? 8-/
То есть, она может предложить план компоновки/укладки деталей сложной формы в печь???
С учетом еще груды дополнительных критериев, по которым они должны выбираться?
Которые в свою очередь не являются простыми критериями, а завязаны на многие другие вещи, с печью непосредственно не связанные (например, с утверждением графика отпусков, ТОиР и т.д. и т.п.)???
Ну, если это так, ты Вы сильно скромничаете... Даже ERP-системы этого делать не умеют... :)

Infinity CreatorА вообще в очередной раз диву даюсь, как вы лихо раскатываете продукт, который даже не видели..Да я и не раскатывал. Вы, наверное, меня с кем-то перепутали.
Более того, искренне желаю Вам успеха. Просто мой жизненный опыт подсказывает, что вероятность его стремится к нулю. Хотя нулю и не равна... :)
Чем черт ни шутит... Вдруг Вы и вправду OLAP придумали, который переплюнет майкрософтовский, да еще и собственными руками его закодируете. Если у Вас это получится, я (честное слово!) готов поставить Вам ящик коньяку! Просто от восторга и радости за самородков, которые случаются в нашем отечестве. :)

Еще два слова про обучение.

Со слов одного моего хорошего знакомого, который возглавляет IT-подразделение в одной из коммерческих компаний. У них тоже использовалась самописка (весьма неплохая, кстати). Но от бизнес-пользователей постоянно поступали запросы в стиле то "сделайте мне вот такой отчет", то "а теперь вот разэтакий отчет"...

В конце концов, когда количество отчетов превысило все разумные границы, и сами пользователи в них полностью заблудились (им стало проще попросить разработать новый отчет, нежели найти старый, который решает нужную задачу), руководитель айти-подразделения настоял на тотальном обучении всех бизнес-пользователей обращению с функционалом MS Excel Pivot Table. В хранилище создали OLAP-куб со всеми мыслимыми измерениями, научили юзверей к нему подключаться и выстраивать сводные таблицы какие только ни заблагорассудится.

После этого на протяжении трех лет больше никто не просил настроить никакой отчет. А пользователям так понравилось пользоваться функционалом сводных таблиц, что они просто пищали от восторга.

Руководитель айти-подразделения получил премию за проявленную инициативу.

Резюме: Ученье - свет, а неученье - тьма... :)

P.S. Кстати, для реализации задач именно финансового анализа Pivot Table + OLAP-куб - наиидеальнейшее решение.