Хочу заняться одной идеей, заодно диплом на ней написать. Сразу оговорюсь, я никого не прошу делать что-либо, так что не посылайте в "Студентам с вопросами о лабораторных работах сюда". Возможно тема не совсем подходит под специфику wasm.ru, но в тут много действительно умных людей с опытом, мнение которых я бы хотел увидеть. Хочу написать систему, оптимизирующую затраты на инкассацию банкоматов. Кратко по теме: В определенный момент инкассаторы загружают деньги в банкомат. Затем эти деньги постепенно тратятся и инкассация проходит снова. Процедура инкассации стоит денег (машина, охрана и.т.д.). Так что, по идее, инкассируй себе пореже и суммами побольше, и проблем знать не будешь. Но с другой стороны - это отвлеченка. Деньги, которые мертвым грузом лежат в банкомате - это убытки. Задача по оптимизации этого процесса легко решается, зная точно какие суммы будут сняты в банкомате в конкретный момент времени. Можно будет например, предсказывая скорое повышения темпов обналичивания денег, загрузить их побольше, чтобы в первые дни большая часть наличных покинула банкомат, а затем будет "откат", в течение которого оставшаяся небольшая часть средств будет равномерно и медленно сниматься до следующей инкассации. Но данной информацией, естественно, никто не располагает. Суть проблемы - на некоторых данных, полученных за определенный срок, выделить некие зависимости обналичивания средств от времени и экстрополировать сей процесс. Таким образом, можно будет понять, в какой момент стоит инкассировать банкомат и какой суммой (причем сказать можно будет однозначно). Процессы эти не случайны. Например: Банкомат стоит в торговом центре - в будни темпы обналичивания значительно ниже, чем в выходные. Банкомат стоит в конторе, которой 2 раза в месяц начисляют ЗП - 2 раза в месяц бедный АТМ будут нещадно опустошать. Кроме того, есть и общие для всех зависимости - праздники, конец квартала и.т.д. Я располагаю данными по обналичиванию средств и инкассаии за довольно длительный период времени. Собираюсь делать выводы на их основе. Для себя уже выдвинул одну гипотезу - зависимость темпов обналичивания средст от времени есть сумма некоторых циклических ф-й с разными периодами (день, месяц, неделя, год). Естественно расчеты здесь будут довольно серьёзными, в чистом виде мат анализ (численные методы) и мат.стат. Может кто скажет, что можно почитать по теме (анализ таких данный с мат. точки зрения)? Ваши предположения? Буду всем благодарен за мысли/критику.
Если есть данные за длительный период, регрессионный анализ тебе в руки (эконометрия). Строишь функцию, которая описывает интенсивность снятия счета + погрешность + влияние "сезонности" и т.д. Потом на основе этих данных программа делает прогноз на уровень необходимой наличности на конкретную дату. Так определяешь нужную сумму. А вот как определить, когда надо приносить деньги, а точнее, с каким запасом - то тут я уже не знаю
Span Ну что ж... начнем по порядку... Деньги никогда нигде не лежат мертвым грузом... Когда деньги загружаются в банкомат, - они приобретают безналичную форму и продолжают свой оборот в безнале... Когда деньги снимают с карточек, происходит обратное превращение из безнала в нал. Инкасация - дело серьезное... И к таким сведениям допускают далеко немногих (я вообще не понимаю, откуда ты взял данные) ... А раз так, то в случае каких-либо изменений, банковский служащий, отвечающий за инкасацию, должен без труда управлять твоей программой... Короче говоря - твое дело - обеспечить простой и гибкий интерфейс. Ахха. Эконометрия - здесь самое оно.
а кто будет вводить эти данные в твою программу? ты подумал о совместимости журналов банкоматов разных моделей или о разновидностях используемых в наших банках ОДБ и представляешь себе как часто они обновляются? ты будешь сутками работать только на апдейты! но допустим тебе удалось получить статистику за прошлый год, ты думаешь она прокатит и на этот? нет, достаточно появится ещё одному банкомату в соседнем квартале и она пойдет на перекосяк, а темпы роста з\п в каждой организации учитывать? на статистику никто не смотрит, т.е. конечно зав.кассой знает сколько и когда жрет её банктомат, но действует она по другому принципу: - либо заправить по полной и не парить мозги - либо заправить на половину, а часть налички продать за безнал с % другому банку - либо заправить сколько есть и ждать пока сдадут ещё налички, чтобы не покупать за % в реале поверь, получается так, что инкассацию приходится делать чаще чем планируешь... то застряла купюра в кассете, то кто-то карточку не туда впихнул, то закончилась журнальная ленточка, то кому-то карту заблокировало, то тех. обслуживание и т.п.
Спасибо за советы и комментарии, буду смотреть в сторону регрессионного анализа и эконометрии. Теперь по порядку: 2 nitrotoluol Окей, вот пример: Есть 2 000 000 для инкассации. Можно загрузить 2 раза по 1 000 000, а можно 2 000 000 сразу. 1 000 000 снимают за неделю. Загрузишь 2 000 000 - хватит на 2 недели. Загрузишь 1 000 000, а потом опять 1 000 000 - хватит также на 2 недели, но "второй" лялик ты сможешь крутануть в первую неделю. Как крутить - уже забота самого банка. Вот этот лялик я и назвал в своём посте "мертывым грузом", пока он просто лежит в банкомате. Таким образом, если повторная инкассация будет стоить, скажем, 1 000, а банк за неделю с 1 000 000 сможет получить 2 000 - то выгодней инкассировать 2 раза. Ну а если инкассация будет стоить 3 000 - выгодней инкассировать 1 раз. П.С. Все приведенные цифры взял из головы. Естественно, действительности они не отражают. Абсолютно согласен, интерфейс здесь очень важен. Рассматриваю вариант с веб-интерфейсом (благо опыт есть). Остальную часть (метематика, часть работы с БД) хочу выделить в отдельный модуль для ПХП. 2 bogrus Для меня здесь нет разницы, какая модель АТМа используется. Никто не испорит, их великое множество, кроме того, у всех разные протоколы работы с хостовым ПО, разная логика и разные форматы представления данных. Импорт данных будет проводиться не из "фронтальной" системы, куда попадает первичка. Основные поставщики банковского (а точнее карточного) ПО приводят все операции в банкоматах к единому формату в своих БД. Я знаю по карайней мере 2 основные конкурирующие системы в России, обе поступают одинакаво. Импорт даннх уже отлажен. Будет применяться своего рода "шлюз" для импорта. Работает через ODBC, в нем настраиваются скрипты импорта данных и указывается DSN, натравливаются на индексы. Один раз настроил - дальше система работает сама (естественно, до обновления структуры БД). Импортируемые данные - успешные снятия наличных и инкассации. Думаю этого будет достаточно для того анализа, о котором идет речь. А об одназначности решения, да и вообще о его возможности никто пока и не говорил ))) Кроме того, как только программа понимает, что ее данные идут "на перекосяк" с реальностью - погрешность увеличавается, и для анализа ищуться иные даные (уже не за год, а за неделю/месяц). Не совсем так... Достают плохие купюры/карты и меняют ленту немного другая служба. Они отвечают за сервис, и, как правило, относятся к другому подразделению, нежели касса. Дыке вот задача программы и есть - помочь этому человеку сделать правильный выбор и ответить на эти вопросы. А эффективность можно будет потом легко определить: Поставить на тестовыю эксплуатацию, скажем на месяц. Посчитать затраты на инкассацию за этот месяц, и сравнить с затратами, полученными при моделировании другого порядка инкассаций с помощью программы. Что есть fft???
Оффтоп, конечно, но проект удался. в качестве методов прогнозирования использовал нейронные сети. Появилась идея написать библиотеку. Только быструю и удобную.
С нейроными сетями замучаешься. Мало того что неизвестно как они будут думать после обучения, так еще затраты ресурсов компа непомерные. Да и спец. аппартные средства для реализяции сетей стоят астрономические суммы. Лучше или реализовать использую или ТАУ или математическое моделирование. В обоих случаях придется постоянно вводить поправку. Если уже не в моготу, то лучше использовать нечеткие множества, чем нейронные сети - обучать труднее, но более надежней.
Многослойный персептрон. Слоя всегда 3. Количество нейронов во втором слое варьируется в зависимости от размера обучающей выборки.
... а можно сделать так, чтобы банкомат посылал информацию о том, что с него требуют денег и сколько ... туда куда надо - и на период "обучения" заряжать побольше. может найдётся хотя бы 1 чел, который сможет проанализировать данные и сделать поправку на праздники, которые планируются ... компутерную систему для автоматического принятия решений имеет смысл делать когда процессы как-бы непрерывные и такие шустрые, что человеческий мозг не поспеет - управление прокатным станом, задачи динамики полёта ... всякие ...
Да, намучался я с ними) А аппаратные затраты не такие уж и большие. Алгоритм обучения писал "с нуля". Где мог - оптимизировал. На мощном домашнем компе (2-3 ГГц Intel Core2) на обучение сети по 1000 образам в 10 000 циклах уходит несколько секунд. Это время вполне соизмеримо с временем выборки данных из БД. Памяти вообще почти не ест. Насчет нечетких множеств - краем уха слышал, надо бы почитать что-нибудь. Единственная проблема - для хорошего результата много времени уходит на подготовку данных. Сделать это в автоматическом режиме не получается... Но прогнозы все-таки получаются неплохие) Беда только по праздникам. Сеть понять не может как ей работать под новый год и.т.д. Если кому надо - могу алгоритм обучения выложить. Я его и для распознавания образов использовал, неплохо получалось.
Span Интересно, а в банкоматах есть датчики наличия-отсутствия денег? Настраивай такой датчик, чтобы подавал сигнал, что осталось 5% от заложенной суммы. Пока инкасаторы подъедут эти 5% и будут "съедены". Второй пункт - ну расчитал ты потребность банкомата от инкассации до инкассции в 10.000.000$ а этот банкомат взяли и взломали - кто будет покрывать эти убытки если они перекрыли затраты на инкассацию? ("Не складывай все яйца в одну корзину")
Там не датчики, а счетчики. В любой момент времени ты можешь снять данные счетчиков, и узнать сколько купюр какого номинала осталось. Хотя это и не нужно. В моем ПО есть данные о том сколько загрузили, и сколько сняли, т.е. можно остатки просто посчитать. Фишка в том, что при нельзя всегда действовать одинаково. Быть может эти 5% снимут за час, и надо срочно инкассировать, а возможно, что банкомат будет еще неделю стоять с этими 5%, и инкассация будет совсем не к месту. Вот для поддержки принятия такого решения я этой темой и занялся. А насчет убытков от действий воров - это уже другая тема. Это риски, их надо оценивать. Кроме того, такие вещи как правило страхуются.
Вот так и получается... Для успешной работы приходится многое делать вручную (задумываться о праздниках, о поломках, делать предобработку данных). Т.е. автоматизировать получилось только часть.
