|
|
Главная /
Технологии /
Учет, отчетность, налогообложение / Отчетность /
7 способов облегчить подготовку отчетности для Банка России
|23.06.2009 06:19|
7 способов облегчить подготовку отчетности для Банка России
© 1999 – 2012 ИА "Банкир.Ру"
:) Повеселили :) Автоматизировали самые элементарные отчетные формы - и крику на весь мир :) Вот когда автоматизируете хоть одну приличную форму (хотя бы ту же 135, на которую замахнулись), а потом посопровождаете ее год-другой, тогда приходите, поговорим.
А пока - извините, но хвалиться вам нечем. И не надо рассказывать сказки, что после сбора информации в хранилище нужно нажать одну кнопку и получится отчет. А ссылки на американскую практику - вообще не корректны (в силу специфики нашей отчетности).
Во-первых, там нет проводок проводок в архивные даты. Значит, по итогам дня достаточно только один раз загрузить информацию и отчетность можно выпускать. А у нас изменения в архивый день идут весь месяц, а то и больше. Т.е. постоянная перегрузка информации.
Во-вторых, сжатые сроки представления (т.е. на эту пресловутую перегрузку изменений в архивные даты просто нет времени).
В-третьих, у них публикуются подходы к отражению тех или иных операций. А у нас - алгоритмы расчета.
Ну и в-третьих, значительная часть отчетов для ЦБР - статистическая. Это означает, что при ее подготовке используются данные, которые не нужны для бух. учета. Т.е. ответ. исп. должен соответствующим образом раскрасить первичку. А кто будет проверять эти раскраски? Правильно, отчетник. А что делать, когда выходит новая отчетная форма или изменения в старую? Правильно, добавлять раскраски. И чем в этом случае может помочь хранилище? Ничем.
Так что хранилище - вещь нужная и полезная... но без ручного труда все равно не обойтись... Особенно при подготовке отчетности ЦБР.
с хранилищами вообще беда . Отчетчик правильно подметил , что работа в архивных днях - это жесть. Причем ладно с бух учетом. Немножко потрудились - сделали сами. Работает. НО подрядчик конструктива не предлагал ни разу. причем всегда - если что -то не идет - позиция подрядчика - А у вас тут данные поменялись . И труба. Хранилище "в топку" - так как им пользоваться не возможно, и "Да здравствует Excel!" .
Со сделками все печальнее может быть. Я так подозреваю , что решений на этот счет ни у кого хороших (автоматических и прозрачных) нет.
А когда данные нормальные - проект сделать уже не трудно . Считалки для отчетности по известным алгоритмам нарисовать - дело времени.
Уважаемые комментаторы, приятно, что статья не оставила вас равнодушными. В наше непростое время ваше чувство юмора – серьезное достоинство.
Разберу ваши замечания по сути. 1. 135 форма – будет готова примерно через 9 месяцев, после того как соберем исходные данные для нее. Какие-то расшифровки будут запущены раньше, по мере ввода модулей сбора. И об этом я обязательно напишу, возможно, снова на портале «Банкир.ру». 2. Этот сайт - не место для сказок, отчеты бывают разные. Какой-то отчет выпускается сразу после загрузки, некоторые – после дополнительных классификаций и расчетов. 3. Когда в учетной политике банка бардак, то и архивные изменения идут весь месяц, а то и больше. В «Газэнергопромбанке» этот процесс регламентирован и четко соблюдается. Время загрузки архивных изменений известно и вписано в общий регламент. Так что есть возможность «один раз загрузить информацию и отчетность можно выпускать». Если у Вас постоянная перегрузка информации, то советую начать с разбора причин возникновения таких изменений… 4. Напишите мне на почту (kuvykin @ iso.ru), договоримся о времени, я с удовольствием продемонстрирую, как перегружаются архивы, почему на это ЕСТЬ время и как выпускается отчетность. В дополнение предлагаю вам вот такой материал об отчетности для БР: http://www.iso.ru/cgi-bin/main/public.cgi?id=235 5. Ваше представление о хранилище как о наборе таблиц с данными несколько не совпадает с нашим. Инструменты для автоматизированной и ручной «раскраски» мы представляем в полном объеме, и это я также готов показать вам. Но вообще-то корректнее, на мой взгляд, всю информацию заводить в учетные системы и ее держать там, учетные системы больше к этому приспособлены. Но это, к сожалению, не всегда возможно. Сумеете ли Вы в своей АБС добавить с десяток атрибутов с той же легкостью, что и я в наше хранилище? 6. Ручной труд всегда будет, задача – минимизировать его.
Как уже было сказано, буду рад продолжить дискуссию по e-mail.
Евгений Кувыкин
Отчетник, по всем пунктам не согласен, особенно по третьему (их у Вас 2, имеется в виду последний "Ну и в-третьих..."). Хранилище данных штука сама по себе замечательная, и лучше всего оно как раз помогает в настройке "раскрасок" (т.е. классификаций) и расчетов. Их можно достаточно просто мастерить, используя функционал ХД, предоставляемый разработчиком, и редактировать в случае необходимости (например, при измененях в регламентирующих документах от ЦБ). А то, что проверять (и править) их необходимо отчетнику - кому же еще это делать? И что вообще должен делать отчетник, если расчет формы автоматизирован? Автоматизация расчета формы не предполагает исчезновение "ответственных исполнителей" ;)
Мимоходом, мысль непонятна, требуются пояснения. На какие лавры претендуют эти нахальные детишки? :)
Похоронилищам, без Хранилищ "беда" еще хлеще, совсем беспросветная. Хранилища для того и нужны, чтобы беду локализовать и, по возможности, ликвидировать. Если Вы "немножко потрудились и сделали сами", причем "все работает", то причем тут подрядчик (о ком речь, кстати) и какой конструктив он должен был предложить? Насчет сделок - все всегда ровно настолько печально, насколько качественны (а точнее некачественны) первичные данные. Даже если отправить Хранилище "в топку", безобразия в учете от этого меньше не станет. "А когда данные нормальные - проект сделать уже не трудно" - святая правда, но оценить их нормальность с Хранилищем существенно проще, не "отвлекая" учетную систему от выполнения ее прямых функций (как правильно заметил PG, в т.ч. для этого Хранилище и нужно).
Коллеги, в пылу спора не будем забывать, что Хранилища Данных нужны не только для автоматизации выпуска обязательной отчетности для ЦБ.Через 9 месяцев (со слов Евгения :)) в Хранилище будет ежедневно загружаться (очищаться и трансформироваться) очень много разнообразной информации, которая пригодится не только для формирования 135 формы ;).
Мимоходом, Вы считаете эту дорогу тупиковой? Не томите, напишите что-нибудь кроме "насмешили", "не первые" и "лавров не достойны". Чувствуется недюженный опыт (судя по всему отрицательный), расскажите, пожалуйста, поподробней, как Вы раньше скромно и без крика (позор Интерсофту!) "заводили хранилища", пока не поняли, что дорожка "торная". :)
Статья обыкновенная, похожа на все статьи о хранилищах. И нападки привычные - как всегда неконструктивные. А вот ответы на них достойные, только сразу понятно, что все положительные слова - это от сотрудников интерсофта. К сожалению, работники банков (в т.ч. it-подразделений) мало знают о технологии хранилищ данных . Для большинства из них ХД - это типа "из одних таблиц в другие переложить и все сразу само работает". Мне один раз вообще сказали, что хранилище - это работа для тупого сисадмина. Позовем студентов на практику и построят они нам хранилище. ;-)
гыгыгыгы.....коменты жжгут!
В 10-ке и ниипет!!!!
гыгыггыгы
:-D
Несколько комментариев к комментариям. :)
Отчетник и Похоронилищам , вы подняли крайне важный вопрос по работе с архивными датами в условиях жизни с ХД. Позволю себе с вами несколько не согласиться, что западные и российские стандарты учета сильно отличаются в данном вопросе (они отличаются, но совсем иными принципами). Работа с архивными датами подразумевает, что с ними работать не надо совсем. :) Если данные за день "закрыты", то они признаются правильными и дальнейшая оперативная работа с ними прекращается. Далее возникает вопрос: что же делать с ошибками, которые подло прокрались в эти архивные дни? Для этого существуют операции сторнирования, которые подразумевают не только отмену операций, но и их исправление. Естественно, что производить такие операции необходимо в учетной системе (АБС) и регламентироваться это должно учетной политикой. Данный подход приведет к тому, что необходимость перезагружать данные просто отпадет.
К сожалению, как правило, происходит следующее. Начинают отменять или изменять операции, которые уже зафиксированы, и это порождает необходимость делать столько изменений, сколько мест, где данные операции фигурируют, в т.ч. и в ХД. И это приводит процессу перезагрузки данных. который действительно занимает приличное количество времени. Таким образом, это не проблема ХД, а проблема орагнизации учета, которую тоже можно решить разными способами. Одним из которых является выработка корректных правил учета в конкретной организации (наиболее правильный путь, но и наболее сложный с точки зрения организационных мероприятий), вторым - некоторое решение, которое может быть использовано в рамках автоматизации той или иной задачи конкретного заказчика (тут все зависит от специфики заказчика, и порой данная специфика отнюдь не тривиальна).
По поводу классификации ("раскрасок") исходных данных могу отметить, что есть два пути:
1. Прямой - установка значений таких признаков на этапе возникновения информации (Первичный и повторный ввод в АБС). Автоматизируется в рамках АБС.
2. Косвенный - установка значений на основании некоторых выработанных правил отнесения данных к тому или иному классификационному признаку. Автоматизируется в рамках функционала ХД.
Если говорить об автоматизации "сложных" форм, то собственно сама их автоматизация никаких проблем не вызывает. Проблему вызывает качество данных и достаточность правил учета заказчика.
Мимоходом, в статье речь идет не о Хранилищах данных как таковых, а об определенных проблемах при подготовке отчетности ЦБ, т.е. о некотором приложении, которое использует данные ХД для формирования отчетности и предъявляет свои требования к исходным данным. Про торность пути можно говорить много, но каждый такой путь оканчивается при начале работ с определенным заказчиком, у которого свое видение "торности". :) Если бы была возможность сделать универсальное решение, то, не совмневаюсь, оно бы уже существовало. Пока такого не наблюдается. И еще... Если людям нравится их проделанная работа, это еще не означает, что они претендуют на "лавры". Разве не так? ;)
Конкурент: В чем-то я соглашусь про "хранилище - это работа для сисадмина", но не совсем сисадмина. Имхо, в условиях огромного количества данных из разных источников должен быть администратор данных (Хранилища данных) и не один. Должно существовать структурное подразделение, в задачи которого как раз и будет входить определение достаточности и качества данных Хранилища. А уже конечные пользователи тогда действительно будут заниматься своим прямым делом.
Спасибо за внимание. :)
На самом деле не во всех банках есть Хранилища, не все IT-шники их могут написать, а потом еще и сопровождать и проводить интеграцию в другие программы.
Вот с очисткой данных и развлекаемся .
У хранилища есть еще один мега плюс - Архитектура удачнее для анализа данных за большие периоды. И не отвлекает ресурсы АБС.
А вот контролирующая функция может АБС и вовсе "положить". Это из опыта. Как-то перестарались.
если у кого-то есть сделочное хранилище - то как сделали контроль за изменениями в архивных днях фактических операций ? Фиксируете баланс по срокам? Или ведете регистры задолжностей с оборотами по этим регистрам ?
to Iridium: а вы идеалист.."откаты" дней в АБС это очень распространенная явление, искоренить которое невозможно никакими учетными политиками (тем более их формально не существует - следовательно учетная политика регулировать это не сможет) - всегда будут объективные причины, по которым банки не захотят афишировать те, или иные ошибки. А так как это можно считать сложившейся практикой (возможно негативной, но сути дела это не меняет), то лично моя позиция заключается в том, что разработка хранилища, учитывающего данную особенность отражения операций в бухгалтерском учета это все таки проблема разработчиков - иначе их замечательный продукт можно использовать только в идеальном мире.
to Кувыкин: Уважаемый Евгений.
"Ваше представление о хранилище как о наборе таблиц с данными несколько не совпадает с нашим."...очень было бы ознакомиться с вашим представлением. Насколько я имею возможность судить то хранилище Контур 2.5 представляет из себя именно набор таблиц с данными (какими именно - сырыми, раскрашенными, сгенерированными, с планами показателей или справочниками классификаций - это вопрос вторичный) и процедур, обрабатывающих эти данные с использованием данных из одних таблиц для раскраски (либо создания новых данных) других таблиц. Причем по структуре (особенно в части сделок) я бы не стал утверждать, что структура хранения в Контур отличается какием-то особенными уровнем оптимальности по сравнению с современными АБС.
Всем:
Про автоматизацию отчетов "по контурски" и снижение нагрузки на специалистов отдельный рассказ. Давайте разберем пример какого-нибудь простого управленческого отчета - например управленческий баланс, представляющий их себя по сути перегруппированный бухгалтерский баланс. Для получения данного отчета в Контур 2.5 необходимо
1.Выгрузить данные из АБС (кстати добрый совет - поручите разработку процедуры получения данных из АБС Разработчику - в случае чего он не сможет отвертеться и сказать, что это вы не поставили данные в нужном формате в его драгоценное хранилище.)
2. Произвести загрузку данных в Контур (в 2.5 скорость загрузки это отдельная лебединая песня)
3. произвести классификацию остатков согласно справочника классификации (по простому раскраску согласно таблице маппирования)
4. на основании плана показателей (грубо говоря еще одного справочника) произвести создание агрегированных документов из классифицированных данных - по идее дальнейшая работа с агрегированными данными должна ускорить время подготовки отчетов. (но тут есть одна подлость о которой чуть позже)
5. получить отчеты (через генерацию OLAP-куба..либо через BI)
То есть для создания 1 отчета мы должны создать и поддерживать в актуальном состоянии как минимум 2 справочника (а на самом деле возможно и больше) - справочник классификации и план показателей. Кажется мало, но поверьте, что мало только сначала - разработчики очень любят для создания новых отчетов создавать т.н. альтернативные планы показателей ( то есть планы, нижний уровень у которого образуется из статей основного плана). Соответственно при внесении изменения в основной план придется проверять и актуализировать все альтернативные. Учитывая слабость интерфейсов Контур для редактирования справочников (например зачастую отсутствует возможность подстановки номеров статей в справочник классификации несмотря на то, что соответствующий план со всеми статьями присутствует в системе, про остально промолчу.), это увлекательное занятие, уже не оставит времени для проведения какого-нибудь анализа.
Что касается механизмов выверки данных из отчета - то они фактически отсутствуют - при расчете аналитических документов (и соответственно агрегации) (вот та самя подлость!) теряются признаки, позволяющие однозначно понять откуда взялись те, или иные значения. Сверять придется на ощупь. И времени у вас уйдет на это столько, что 10 раз уже можно будет сделать этот отчет руками.
Итак краткий итог - нужно ли хранилище данных? Да..все таки нагрузку на АБС лучше снизить за счет хранения данных для построения отчетов в другой базе. Нужен ли именно Контур? Нет - Если у Вас есть современная АБС, в которой содержится достаточный набор данных для построения отчетности,толковые программисты и люди, знающие методолгию - Вы сделаете все сами так, как Вам нужно - создадите свое хранилище для ваших нужд, с навешиванием ваших аттрибутов, а если нет, то Контур Вам не поможет тем более - только создаст проблем.
to s2k2000
Добавим , что с первого раза загрузить не удастся , так как в данные прошлых периодоах вкралось изменение - которое можно найти только артиллерийским методом - итерациями вычисляя дату расхождения. в 2.5 действительно - теряются источники данных после аггрегации да и сама аггрегация невероятно медленная.
НО , если, таки,рождается структура с нормальным описанием объектов и свободная от операционного функционала и груза - то на этом можно нормально строить хранилище.
правда это так редко бывает . По крайней мере решения по Ценным бумагам я еще ни разу не видел в хранилищах.
на специализаированом ранилище можно вычистить данные - это тоже плюс . Но ресурсы и время - это минус , зато светлое будущее - это плюс!
Я за хранилища и методики контроля и загрузки.
Под 2.5 - сами писали. Под сделки - пишем но пока только в ЦФТ.
to Похоронилищам^
Ключевое слово "ЕСЛИ".....если есть видение то, что необходимо....построите и сами......а если будете уповать на то, что придет Трастконто со своими "рыбами" (и будет убеждать вас в том, что то их видение, это то самое, о чем Вы мечтали (а ведь будут - они пытаются положить Вас под систему - попробуйте ка им свое видение навязать..устанете)).....и будет у Вас щастье и Управленческий учет - бросьте это дело сразу. То же самое и с отчетностью ЦБ......можно и свое сделать.....и по качеству будет получше Контура...и интерфейсы будут сделаны для работы, а не для мучения...
а светлого будущего в области отчетности не будет...я Вас уверяю.....если с управленческой еще более менее (всегда свои аппетиты можно отрегулировать)....то с Цэбэшной это вечное удовольствие :))))))
to s2k2000:
"То же самое и с отчетностью ЦБ......можно и свое сделать.....и по качеству будет получше Контура...и интерфейсы будут сделаны для работы, а не для мучения..."
1) Получается, что как ни пиши, будет все равно качественней "Контура"?
2) Откуда Вы взяли, что интерфейсы "сделаны ..для мучения"? Вы же их не видели. Интуиция? :)
to собеседник:
по вопросам:
1).....нет не получается.....об этом я не говорю.....я говорю о том, что если в Банке есть грамотные методологи и квалифицированные программисты, то они в силах создать решение, оптимально адаптированное под потребности конкретного банка в разумные сроки. Со всяким консалтерами обычно связываются тогда, когда нет своего понимания, и результат выходит соответствующий. А Контур это больше PR на самом деле...никаким "промышленным" (тоже придуманный термин - для повышения значимости) решением это назвать язык не поворачивается.......
2) А с чего Вы взяли, что я их не видел...как раз я их видел.....иначе я бы придержал бы свои комментарии.. И сделаны они действительно ужасно...но самое плохое даже не это, а нежелание разработчиков учитывать пожелания пользователей...все из под палки будет делаться :) А вам будут рассказывать о том, что это такой функционал системы :)
to s2k2000:
Вы про какие интерфейсы пишете? Я так понимаю совсем не про те, о которых обсуждаемая статья.
я про те где пользователям придется ручками справочники заводить и редактировать их потом....те самые "инструменты для автоматизированной и ручной «раскраски» представляемые в полном объеме.."..то что должно делать работу пользователей с системой легкой и непринужденной...и экономить их время и силы.........с целью повысить их эффективность........те, которые должны использоваться для выверки данных....вот о каких интерфейсах я говорю.....
Читаю эту замечательную дискуссию, много интересных и совсем неинтересных мыслей, субъективных мнений. Так что, нужно ли ХД для подготовки отчетности?
Если у Вас нет филиалов, одна АБС, в которой отлажена технология учета всех операций, выстроенная учетная политика, строгий регламент и "железная рука" сверху, когда шаг в сторону простым пользователем - сразу "расстрел на месте" (где ты. Светлое и Прекрасное Будущее??), тогда, наверное, возможны споры, нужно ли ХД или АБС все потребности в отчетности закроет (особенно если нет физиков, операций в день пару десятков тысяч - это нонсенс, перебор и надо срочно в отпуск на месячишко после такого стресса)... А вот если у Вас десятка три-четыре филиалов (при этом вполне себе самостоятельных, с правом "подать голос"), АБС Вам децентрализованную (а то и не одну, ни разу не западную (и слава Богу!!!) , не очень гибкую и с возможностью бить проводки напрямую, править данные за несколько месяцев назад и т.д.), еще три-четыре немелких системы для фин.сектора, процессинга и т.д. и прочие "ужасы"... Интересно, из какой из этих систем Вы в итоге будете выпускать консолидированную отчетность? Не важно какую - управленку, обязательную или любую другую?
Напрашивается единственный вариант - ХД, но, разумеется, это не панацея. Строить ХД надо с умом, а не надеяться на то, что взяли ХД, и оно сразу решит все проблемы. Иначе будет, как часто это бывает - ХД есть, но почему-то в итоге одно Х, т.к. Д в нем либо нет, либо Д какие-то Х...
Можно построить ХД собственными силами?? бесспорно!!! наверное... Чтобы учесть все-все-все свои нюансы и потребности, специфику и т.д!!! Правда, дело хлопотное, команда своя может и не добежать до финиша - декреты, творческие кризисы, разногласия, не дай Бог - болезни, а то и заметят, позовут куда "повыше да побольше"... Либо даже можно и добежать куда-то, и а потом опять же все то же... вдруг раз... 302-П... нестрашно, ночами поработаем, поправим... покупаем дочерний банк? открываем филиалы? меняем АБС? ... мы так не договаривались, это мы не проходили, это нам не задавали... вы даете нереальные планы!!! В итоге есть какое-то ХД (как раз тот самый набор таблиц, про который писали выше), кто-то в нем что-то писал, какие методики, алгоритмы и т.д. в него зашиты - никто уже и незнает, все архитекторы давно не здесь... А отчетность выпускать надо.
ХД от стороннего поставщика - купить готовое ХД ("набор таблиц" по мнению некоторых, что весьма спорно...) и считать, что все проблемы решатся сами собой.... примеров множество, результат - всегда отрицательный, это утопия. Хранилище само по себе не решает все проблемы, но при правильно подходе проект анедрения ХД позволяет выявить множество системных и технологических проблем, в первую очередь, связанных с первичным учетом, качеством данных, и позволит в дальнейшем уже отстраивать "автоматизированную" систему, когда реально будет форировать множемство отчетов "по кнопке", не задумываясь о проблемах сбора и выверки данных - это вопрос далеко не одного года. Без четкой регламентации процессов внутри банка, построения согласованной учетной политики и технологии первичного учета нельзя от ХД требовать, чтобы оно творило "чудеса" и их ничего делало что-то полезное. Правда, по дороге, желательно получать локальные, но весьма полезные результаты в осязаемые (несколько месяцев) сроки, а это как раз вполне возможно.
Итог (ИМХО): ХД в Банке строить можно и нужно!!! Причем, можно, конечно, пытаться изобретать по пути множество велосипедов и других транспортных средств, а лучше бы воспользоваться уже имеющимся опытом и проверенными инструментами. Основная ценность сторонних поставщиков - не "законченные решения", которые они могут предлагать, а проектные команды, состоящие из опытных специалистов, сделавших не один проект. Причем не где-то, а именно в России. Этот опыт бесценный, и именно за него в конце концов платятся деньги. Если есть предметная заинтересованность, желание со стороны Банка действительно решать задачу, удается собрать хорошую команду со стороны Банка и исполнителя - то результат будет. Если заплатить постащику "N денег" (желательно поменьше) и ждать от него чуда, не прилагая со своей стороны адекватных усилий и не затрачивая ресурсы (это и месяцы работы своих сотрудников, и деньги на услуги поставщика, и "железо" и т.д.), то положительный результат вряд ли будет получен. Если брать обсуждаемый здесь Контур, то обратитесь к таким их заказчикам, как ТКБ, Еврофинанс, Газэнергопром, Возрождение и т.д., я думаю, они поделятся своим опытом.
И тогда не будет никаких вопросов, о которых пишет уважаемый s2k2000: "(в 2.5 скорость загрузки это отдельная лебединая песня)". А какие усилия Вы прилагали, чтобы эту скорость поднять? Что является причиной низкой скорости? Я сышал, что, например, в ТКБ с их количеством филиалов (~40), объемом данных (терабайты) и количеством одновременно работающих пользователей (за 100) Контур версии 2.5 вполне справляется. Насчет скорости загрузки в 3.1 (про которую, как я понял, была статья) наверное лучше задать вопрос тому же Газэнергопромбанку...
Относительно неудобства интерфейсов и нежелания разработчика что-то дорабатывать под требования пользователей: эргономика интерфейсов - вещь достаточно субъективная. Вообще-то "ручками справочники заводить и редактировать их потом" - это не совсем задача ХД, возможно, правильнее, первичный учет вести корректно в учетных системах? а ХД, особенно "промышленное", хотя этот термин и не очень нравится уважаемому s2k2000, предназначено для решения очень широкого круга задач, и соответственно, не может в полном объеме изначально соответствовать Вашим субъективным потребностям в ведении какого-то отдельного вполне конкретного справочника, и его последующего редактирования по только Вам известным принципам и причинам? Для этого в системе, наверное. существуют открытые средства разработки - никто не мешает Вам ими воспользоваться и разработать свой супер-универсальный-удобный-и-полезный-для-здоровья интерфейс, который будет сделан для работы, не для мучения, а для удовольствия... Или в конце концов, если не хочется/не можется сделать все своими силами, может, стоит отдать вполне четкую постановку задачи для поставщика системы, заплатить ему денег за разработку и принять результаты, котрые Вас устроят? Неужели поставщик и в этом случае откажется от денег или сделает все настолько некачественно, что работа с системой останется мучением, если не сказать, каторгой? Что-то не очень верится...
В общем, Коллеги, спасет нас опыт и стабильное финансирование :)
to PK po FER - NFS(GB): Наверное бывает и каторгой. Потому как, те кто продают - пытаются продать то, что у них есть , а те кто покупают - не знаю чего хотят .
Без понимания на месте того что надо сделать - ничего не получится . Проходили .
самопальный проект тоже ничем хорошим не заканчивается . Причины описаны. Он и дороже получится и грубее в итоге. Из овчинки можно и 8 шапок сшить - был такой мультик. Простой расчет это покажет.
Опять же - если понятно какие отчеты хочется иметь . И под них сделано хранилище - остается всего один шаг в этому - наполнить хранилище. Да , это самый сложный шаг. Да, странным образом для бизнеса он оказывается самым медленным и дорогим. Но если его не сделать - то хранилища не будет.
Скорость загрузки - важно, но ее кратные колебания в 3 - 5 раз ситуацию НИКАК не меняют . Так что гоняться за ней особо не стоит . лишь бы был запас по времени - не менее 16 часов в день . Т.е. загрузка занимала не более 8 при локальных пиках в сутки.
Далее распределение расчетов и загрузки в течении дня и даже с критическими моментами можно српавиться. Так что пиариться по скорости - смысла нет. Она должна быть просто необходимой.
А вот снижение нагрузки на АБС - это важно. попробуйте положить работу системы , когда ТОПам нужен срочный отчет - они первые поднимут шум , так как им нажалуются приведенные ими же клиенты. И это замкнутый круг .
Хранилищу, причем, стороннему - быть . пониманию со стороны покупателя - быть еще важнее. самопальным решениям, кроме контроля данных - не быть .
ээээх - финансирование. Нормальное финансирование - это мечта. И по системам и по кадрам. Кто-нибудь пытался ради экономии работать на OpenOffice на работе с реальными объемами данных? Это как сравнить жикули и бмв вроде похожи , колеса и руль, а попробовать проехать 100 000 подряд на время? Тоже , конечно, можно ...
ну поехали по пунктам..
"А какие усилия Вы прилагали, чтобы эту скорость поднять? Что является причиной низкой скорости? "...педали крутили быстрее...шутка....специально для интересующихся и "наслышанных" о 2.5....проблема в самом алгоритме загрузки....просто Контур при загрузке производит фактически построчную обработку XML-файла..соответственно можете представить сколько времении занимает этот оптимальный процесс...и решиться это может только полным переписыванием всех процедур загрузки 2.5......никакое железо Вам не поможет....просто потому что процессы загрузки, реализованные в 2.5 его не могут использовать в полную силу.....сервер просто отдыхает в этот момент....
кстати насчет фраз "я слышал...".."говорят.."....вы поверьте....здесь половина победных реляций это не более чем PR....и причин тут несколько...во-первых те люди, которые отвечали за приобретение таких систем не признают никогда того, что это была ошибка...потому что никто не хочет отвечать за последствия.....никто не хочет сказать что он дурак......поэтому придумываются сказки.....о том как все здорово внедрено...какие замечательные отчеты строятся......какой замечательный у нас разработчик и т.д и т.п. ...... и все это активно поддерживается разработчиками......которые устраивают всякие псевдонаучные конференции, где приглашенные (нахаляву) ....делятся "опытом".....выступают с докладами (вы их почитайте...одни и те же фразы кочуют из доклада в доклад)...некоторые даже пишут статьи (открою секрет - иногда авторство этих "трудов" принадлежит самом разработчику). И все это для того, чтобы окучить еще нескольких сомневающихся. Это уже система. И поверьте, что это мне известно не понаслышке.
Насчет Контур версии 3...да она сырая как кусок теста....тем более она бесполезна на текущем этапе для тех, кому нужно ставить управленческий учет..там просто отсутствует необходимый функционал....а стать пионером внедрения с такими супер-разработчиками это увольте..учитывая что приходится затрачивать ресурсы на сопровождение 2.5 это уже слишком затратно....
теперь об интерфейсе..судя по Вашим словам у меня складывается ощущение, что Вы Контур 2.5 в глаза не видели..поэтому и представления у Вас о нем на уровне "наверно"... Справочники эти служат для дополнительной раскраски данных, получаемых из АБС дополнительными аналитическими признаками (например регистрами УУ), о структуре которых учетная система догадываться не может (да и не должна)..именно для этого и нужно ХД..и интерфейс должен быть продуман таким образом, чтобы затраты на сопровождение этих справочников были минимальными...иначе зачем мне нужен такой интерфейс, по сравнению с которым MS EXCEL это вершина usability.....без нормальных интерфейсов ценность этой системы стремится к нулю...и насчет самостоятельной разработки интерфейса....да все возможно.....только зачем мне тогда Контур для разработки...я разработаю интерфейс без него...и без накладываемых им ограничений.
Кстати позволю себе замечание про проблемы, возникающие при самостоятельной разработке хранилища....все эти проблемы можно поймать и со сторонним разработчиком - и смену команды ( и следующие уже не понимают половины того, что сделано)...и проблему адаптации хранилища к изменившимся правилам учета (то же самое 302-П)....и невыполнение своих обязательств.......и поверьте, что рычагов влияния будет не так много, как кажется.......
а что касается термина "промышленное хранилище данных" - а Вы попробуйте дать мне корректное его определения...и потом посмотрим как Контур 2.5 ему соответствует....
to s2k2000: Я скорее не идеалист, а приверженец такого подхода, а это, в свою очередь, не отрицает наличие "сложившейся практики". И об этом я в предыдущем комментарии указывал и возможные пути решения приведены там же. Учетная политика необходима, в том числе и для того, чтобы недопустить таких ситуаций, иначе это не учетная политика, а так, бумажка какая-то. :) Не соглашусь с Вами и в части того, что решение данного вопроса целиком на разработчике. Данное решение должно формироваться в рамках совместной работы с Заказчиком, т.к. имеет непосредственное отношение к процессу ETL (и прочим процессам последующих расчетов), а он всегда сугубо индивидуален в виду "сложившейся практики" вполне определенного банка.
Относительно "объективных причин" желания банка не афишировать те или иные ошибки, отмечу лишь что это не есть желание банка, а желание конкретного исполнителя(ей) в банке, который совершил(и) ошибку и не хочет ее афишировать, дабы по башке не получить. :) Собственно это относительно простительная причина для не "афиширования", иначе можно предположить, что речь идет уже не просто об ошибке, а о сознательных действиях по скрытию в учете различных финансовых манипуляций. :)
Кстати, приведенные вами шаги выпуска отчета, есть ни что иное, как общий утрированный алгоритм работы по выпуску отчетности из любой системы класса ХД. Для любой подобной системы будет необходимо выполнить эти шаги, разве что часть из них может быть опциональной (например шаг 3, который является по сути одним из видов обогащения данных). Будь ли то Контур, либо какая другая система, если у Вас в ней организуется определенный вид учета, то, соответственно, для его корректного ведения будет необходимость вести справочники и прочие сопутствующие и необходимые информационные разрезы.
И позволю себе еще одно замечание. При наличии "толковых программистов и людей, знающих методологию" из Контура 2.5, да и не только из него, можно сделать хороший и полезный инструмент для специалистов банка любого направления. Т.е. были бы люди, а уж остальное-то приложится. :)
И если Вас не затруднит, то ответьте, пожалуйста на следующий вопрос.
Какие АБС вы считаете современными?
Так как "откат" дня обычно требует отмашки лица не ниже зам.глав.буха, то, поверьте покрыть ошибку таким образом нереально...что касается "сознательности" или "несознательности"....я не буду это комментировать - это картины не меняет.....даже если все этим занимаются сознательно ситуации это не меняет......разработчик решения должен адаптироваться к практике......а не практика под него.
Насчет учета и справочников....это тоже можно делать по разному.......Вы просто не наблюдали как разработчик любит плодить эти справочники (в основном планы показателей) под каждый отчет....например для отчета на дату один план..а под такой же отчет за период уже другой..и вести их нужно 2...хотя они идентичны...и хватило бы одного...но разработчик уже так сделал...и переделывать уже желанием не горит - дескать и так все работает......но ваши издержки на сопровождение становятся выше........и так будет на каждом шагу...
Касательно вашего замечания - если есть толковые методологи и программисты непонятно зачем платить деньги (и не маленькие) еще и за чужое некачественное решение...которое нужно еще доводить до ума (для чего в нем еще нужно и разобраться (дай бог если описание будет толковое) - а уж понятно каждому, что проще создать свое чем разбираться в чужом)...и грузить этим маразмом ценных специалистов - извините, но явно можно найти им лучшее применение.
Насчет АБС - например ЦФТ...
to s2k2000
Абс - ЦФТ - это мечта , особенно по интерфейсам для разработчика.
Накодить там можно все и достаточно быстро.
НО Хранилище - это хранилище . А хранилище у них только по кредитам и депозитам. Остальное надо дорабатывать. Контрольных процедур нет. Истории изменнеий параметров нет . Зато скорость загрузки - запредельная .
признание ошибок и декларирование внедрения - это печальная ситуация.
если есть толковые методологи и программисты = итого 15 чел и год работы , то типа за 150 т (зп) * 15 * 12 = 27 000 т руб можно получить отличное хранилище. правда с багами в движке. И если задумка по движку будет не очень удачной - то мертво-рожденный продукт. "Недорого"
Вставка в архив по проводкам - ерунда . Сложно с фактическими операциями по продуктам. Да их и правят чаще всего без согласования.
Сделали бы и Интерсофте как у оракла - если поставил настроил и понравилось - то лицензируешься. Какую-нить триальную лицензию.
похоронилищам: \
"Сделали бы и Интерсофте как у оракла - если поставил настроил и понравилось - то лицензируешься. Какую-нить триальную лицензию."..они никогда этого не сделают.......иначе никто никогда "это" не купит..
Для примера....я могу точно и однозначно утверждать, что для воспроизводства всей кучи управленческой отчетности, которой гордятся ИСЛ нужна работа 3 человек в течении 4-6 месяцев (кроме этого они еще кучу чего будут делать)....и это не голословное утверждение...есть реальный опыт создания системы, которая контролирует изменения в АБС и обновляет информацию в режиме приближенным к онлайновому. Все отчеты, реализованные на данной системе полностью перекрывают набор отчетов реализованных в Контур за последние пару лет, построенных на балансовых данных..причем если отчеты, построенные на данных Контур доступны минимум через 1.5-2 часа после закрытия дня, то отчеты, подготовленные на основе своего решения доступны максимум через 15 минут после закрытия дня..и сделано было все за 3 месяца....и никаких 15 человек не было...и все прекрасно работает.....стабильней чем в Контуре.....без всяких громоздких глобальных процедур загрузки......пока не хватает сделок.......но они будут (так как мы и поставляем информацию для хранилища из АБС - все процедуры выгрузки данных, разработаны специалистами Банка, а без них - Контур просто бесполезный "промышленный" набор таблиц).. и тогда вообще становится непонятно.за что деньги нужно платить....
Что касается багов в своем и чужом хранилище.......практика показывает - в чужом их не меньше...а исправляются дольше......
to s2k2000:
Ваш практический опыт не совсем понятен. Не могли бы Вы ответить на несколько вопросов:
1. Примерное число лицевых счетов в Вашем банке
(Варианты ответа: 10 тыс, 100 тыс, 1 млн, 10 млн, 100 млн)
2. Число проводок в день
(Варианты ответа: 10 тыс, 100 тыс, 1 млн, 10 млн, 100 млн)
3. Вы привели оценку трудозатрат на разработку некоторого решения ( 3 чел *4-6 мес)
Сколько во Вашему времени потребуется что бы все повторить при смене АБС?
4. Если уже все равно все пишете руками, почему было не писать данные напрямую в таблицы Контур не используя "глобальные процедуры загрузки"
(Варианты ответа: лень разбираться со структурой чужих таблиц, хотелось самоутвердиться при самостоятельной разработке, после тщетельного изучения стуктура таблица Контура оказалось неподходящей)
5. Каким инструментом разработки визуального интерфейса Вы пользовались для собственной системы? Почему Вам непонравилось для этого использовать vcl компоненты дизайнера форм Контура?
to похоронилищам:
"те кто продают - пытаются продать то, что у них есть" - и зачастую идут дальше и продают даже то, чего у них нет!!! - только так и движется прогресс
"а те кто покупают - не знаю чего хотят" - вот это чистая правда!!! А те, кто в итоге осознает, что же ему надо, у тех есть шанс добиться своего и повесить себе медаль на грудь.
to s2k2000:
"а что касается термина "промышленное хранилище данных" - а Вы попробуйте дать мне корректное его определения...и потом посмотрим как Контур 2.5 ему соответствует...." - договориться о терминологии, это уже полдела :) Затруднюсь, наверное, дать "корректное" определение, т.к. не претендую на истину в последней инстанции. Но, по моему мнению, если решение РЕАЛЬНО эксплуатируется в десятках различных банков (и не только) и вполне себе решает поставленные задачи (все или не все, и на 5 баллов, или где-то на "троечку", т.к. не хватило воли/денег/нужных специалистов (не в коем случае не в Ваш огород камень, в том числе со стороны поставщика) - это уже вторичный вопрос), то оно вполне претендует на право называться "промышленным". Как я понял из Ваших постов, Контур у Вас ЭКСПЛУАТИРУЕТСЯ в режиме ПРОМЫШЛЕННОЙ эксплуатации уже не первый год? Просто есть моменты, которые лично Вас или Ваших коллег в работе системы и специалистов поставщика не до конца устраивают... "Мышки плакали, кололись, но продолжали есть кактус" - шутка :)
"отчеты, построенные на данных Контур доступны минимум через 1.5-2 часа после закрытия дня, то отчеты, подготовленные на основе своего решения доступны максимум через 15 минут после закрытия дня..и сделано было все за 3 месяца...." - я уже писал про то, что чаще всего для построения консолидированной отчетности нужны данные из трех-четрыех в лучшем случае, а иногда, при децентрализованной АБС - трех-четырех десятков учетных систем, и ни в одной из них данных недостаточно для выпуска отчетности... Вот, где без промышленного ХД никуда!!! интересно было бы посмотреть на решение, которое при условии не 2-3 тыс. операций в день, а хотя бы 2-3 млн. успело бы данные за день выгрузить, трансформировать, проверить-очистить, загрузить в ХД, сделать классификацию, рассчитать витрины и выпустить отчетность, и все это за 15 мин!!! да сделано за 3 месяца... Больше похоже на скатерть-самобранку, чем на реальную жизнь. Да, можно выгружать в режиме близком к on-line - отдельная история, как ПРАВИЛЬНО отследить ВСЕ сделанные изменения, да не нагружая источник и т.д. Стоимость реализации только такого решения может быть близкой к стоимости пусть маленького, но самолета. Дальше данные надо проверять и чистить. Далеко не все проверки можно сделать по отдельным записям. Часто требуется комплекс данных - значит загрузка идет либо во временную область где все, что выгрузили, накапливается. И только после определенной отмашки идут массовые процедуры очистки, контроля, классификации, и последующая загрузка. Либо вы "быстро" кладете в ХД "грязные" данные в течение всего дня (для ряда задач ими можно пользоваться, бесспорно, но далеко не для всех), и потом все равно вынуждены запускать массовые проверки и т.д..А потом корректно удалять ошибочные данные. И только после этого строить отчетность.
А если у Вас отчеты из Контура досупны через 1,5-2 часа после закрытия дня, то с учетом файловой загрузки это нельзя назвать плохим результатом, хотя не владею информацией о Ваших объемах данных, кол-ве филиалов и т.д., это было в вопросе Григория.
"разработчик решения должен адаптироваться к практике......а не практика под него" - а Вы не пробовали это например SAP'у предложить? пообщайтесь с теми, кто пытался на SAP хотя бы главную книгу собрать - они Вам много интересного рассказать смогут :) Если пытаться автоматизировать хаотичную постоянно меняющуюся практику и адаптироваться под нее, то получится автоматизированный адаптированный хаос, который, как известно, автоматизировать не возможно, соответственно не получится ничего... и видимо никогда (ИМХО).
to похоронилищам: Стесняюсь спросить, возможно вопрос покажется глупым, но чем отличаются фактические операции по продуктам от собственно проводок? У меня есть некоторое непонимание, что Вы подразумеваете под фактическими операциями. Ведь проводки - это тоже по сути фактические операции, разве что бухгалтерского учета. И, как следствие, обсуждение ранее заданных Вами вопросов о "фиксации баланса" или "регистрах задолженности" представляется без данного определения менее полноценным, чем могло бы быть. А тема является очень интересной.
to s2k2000: Относительно "отката" дней и т.п. Разработчик (а вернее не разработчик, а поставщик ПО) не должен предоставлять такое решение, данное решение вырабатывается в рамках проекта внедрения системы совместно с заказчиком в соответствии с практикой ака учетной политикой, принятой в данном банке (при этом, наверное, необходимо уточнить, что это не та политика, которая предоставляется во вне, а ее более детальная версия). Таким образом, ситуации с "откатами" должны быть формализованы и описаны, когда можно их делать, когда нельзя. А так вы отвлекаете крайне занятого специалиста, например такого, как "зам. главбуха", на принятие элементарных решений, которые могут быть ограничены набором регламентных инструкций. Форс-мажор, конечно, никто не отменял и он иногда случается, но и решаться тогда он должен "форс-мажорными" средствами, т.к. подразумевает под собой нестандартную ситуацию. Ну а если учетная политика является формальной, для галочки, так сказать, то тогда можно считать, что практики нет, а есть что-то что как-то где-то каким-то образом учитывается, тот самый учетный хаос, в простонародье, бардак в учете. И соответственно, происходит постоянный процесс автоматизации этого бардака.
Теперь собственно о Контуре, как о "промышленном ХД". Вы совершенно правы. Контур промышленным ХД не является, т.к. ХД промышленным быть вообще не может (если мы под "промышленным" понимаем массовое производство). Хранилище данных организации (банк, холдинг, предприятие ли не важно) всегда индивидуально и выстраивается под конкретные потребности данной организации. Более того в одной и той же организации может быть несколько ХД по разным предметным областям, которые будут решать собственные задачи, если есть такая необходимость. А что же такое Контур и ему подобные программные продукты? Ничто иное, как инструмент для построения ХД + набор некоторых бизнес-приложений, которые несут определенный набор функциональности с той или иной степенью настраиваемости, возможностью разработки и т.д. И, как инструмент, он и прочие продукты вполне себе промышленные. :)
Все остальное, о чем писали Вы, выполняется в рамках проекта построения ХД для каждого отдельно взятого заказчика, в т.ч. это касается и пресловутых процедур выгрузки, контроля данных и т.д. Если для построения ХД привлекается поставщик ПО или сторонний подрядчик, то в данном проекте определяется, что делается специалистами исполнителя, а что специалистами заказчика. И главное - ответственность за успешное исполнение проекта лежит на обеих сторонах, т.к. заинтересованность, хоть и разная, но обоюдная. :) И это касается не только Контура, а всех систем сторонних производителей, внедряемых в организации (в т.ч. и АБС). И вот тут крайне важны проработанная методология, и как следствие, внятные требования заказчика. При их отсутствии любой такой проект обречен на неуспех, неважно на Контуре ли, продукте другого вендора или собственной разработкой решается задача.
Относительно: "так как мы и поставляем информацию для хранилища из АБС - все процедуры выгрузки данных, разработаны специалистами Банка, а без них - Контур просто бесполезный "промышленный" набор таблиц" замечу следующее. Было бы странно если бы информацию для ХД предоставлял Контур, а не АБС (так все-таки: вы или АБС? :)) В принципы ХД изначально заложено, что их нужно заполнять из внешних источников и абсолютно неважно, кто делал процедуры выгрузки (исполнитель или заказчик), главное, что они необходимы для любого ХД. Если вы этот "набор таблиц" (или какой иной) не будете заполнять, то он будет бесполезен в независимости от продукта того или иного вендора. Это равносильно утверждению, что MS Word просто бесполезный "промышленный" белый квадратик на экране без введенного туда текста.
Если я правильно понял, то вы сторонник собственной разработки ХД с "нуля" специалистами организации без привлечения сторонних подрядчиков. Так? Относясь к Вашей позиции со всем уважением, все же отмечу, что многое, для решения такой задачи собственными силами, зависит от масштабов задач сбора данных и задач, которые должно решать ХД (и его приложения). Поэтому хотелось бы узнать об этих масштабах исходя из Вашего практического опыта. Присоединяюсь к вопросам Григория и дополняю их еще парочкой:. каково количество филиалов и сколько источников данных?
to Iridium
насчет отличий между проводками и фактическими операциями :
например :
Клиент внес сумму за кредит - 500$
Линия с лимитом в евро транши в рудлях , долларах США и евро
У клиента есть просрочки по части траншей
Итог: бэкофис в таком кредите может наколбасить ошибок
Проводку в 500 долларов фиксируем - закрываем по максимуму со счетами просрочек , потом проценты , потом основной долг
По лицевикам все понятно . Ну более или менее.
А вот по видам задолжностей и в каждом транше - тут уже не все так просто - могут быть исправления , не затрагивающие бухгалтерский баланс.
Вот с этим и приходится возиться. Причем исправления в балансе производятся только с разрешения гл. буха , а вот в продуктах могут все поменять по-тихому.
причем есть еще интересные моменты - в ЦФТ - для того чтобы вести разные интересные кредиты приходится изобретать разнообразные виды фактических операций. Это еще немного запутывает систему. двойной записи в фактических операциях нет . Т.е. могут быть операции уменьшающие сумму задолжности и изменющее регистр "Итого погашено задолжности" - по таким просто обороты считать , а бывают такие , что делают только одну из операций. В общем по задолжностям возникают различные нестыковки. Они правятся , иногда часто .
ХД - это инструмент -- Это точно ! Можно и свой написать. Но трудозатратно. про 3 человека за 4 месяца . Что-то не верится. Вот в полгода и 4 человека - Можно сделать отличные выгрузки и интерфейсы контроля. потом уже расширять функционал по отчетам.
to Григорий:
1) до 100 т.
2) до 20 т. в день
3) время определяется тем, насколько быстро мы сможем понять структуру хранения данных в новой АБС - после этого быстро.
4) варианты 1 (не вижу смысла разбираться в чужом решении на которое отсутствует вменяемое описание)
5) клиент для редактирования различных справочников и запуска процедур на сервере - на MS ACCESS (его функционала для этого хватает с лихвой)..построение отчетов - ORACLE BI...смысла творить это в контуре не вижу никакого
вопрос 6) (дополнительный) - филиалов нет
предвижу ваши реплики насчет того, что банк у нас некрупный и дескать мои доводы поэтому можно не принимать во внимание - только теперь подумайте, что если Контур на таких масштабах проявляет себя таким образом, как это решение проявит себя в крупном банке. Именно поэтому я считаю - 1.5 - 2 часа в такой ситуации это не результат, а издевательство.
А проблема с кучей филиалов, что со своим решением, что со сторонним будет упираться в наличие у банка нормальных специалистов, знающих структуру своей (своих) АБС - потому что разработчик скажет Вам "поставка данных - ваша проблема"...и вы будете все равно ее решать сами.....так какая разница Вам чьи таблицы заполнять - свои или чужие?
Поставляются данные в ХД решением, спроектированным и реализованным специалистами банка из АБС - слава богу там есть многое из того что нам нужно (а если бы не было - никакой Контур не помог бы) и, так как мы знаем, какие данные нам нужны и как их получить, то уж и написать процедуры для их обработки мы сами сможем не хуже специалистов стороннего разработчика.
насчет откатов - не нужно фантазировать - никто не будет формализовывать то, чего формально не существует (идите сходите с этой идеей к главному бухгалтеру - он повеселится). А вот разработчик должен учитывать подобную возможность раз уж делает систему для российских банков. Но это уже лично мое мнение - соглашаться не обязательно.
Наблюдаю целых 2 подхода к термину "промышленное" решение и еще больше убеждаюсь, что термин искуственный и высосан из пальца - можем с коллегами предложить 3 вариант - "промышленное решение - это решение на сопровождение которого требуются ресурсы целой промышленности"...шутка с долей правды :)
Григорию и Iridium:...а Вы не могли бы тоже ответить на те вопросы, которые задали мне...и хотелось бы знать решение какого производителя ХД Вы внедряли у себя...
похоронилищам: ну скажем так..у нас уже реализован был механизм выгрузки для стороннего решения..поэтому не с полного нуля двигались...и на изготовлении отчетов на данных стороннего решения руку уже набили...именно отсюда и такие сроки...
s2k2000:
очень хочется выяснить реальную стоимость и сроки решения. Так как это 1 из моментов для принятия решения.
Кроме того - вопрос . Как со сделками. Много ли кредитов юрикам ? Большой ли портфель бумаг у банка. Есть ли клиентские бумаги ? активно ли торгует ? больше 500 или меньше 500 видов бумаг?
Собираете ли кредитный портфель из хранилища ?
ресурсы для создания своего решения я уже озвучивал.....включать сюда сроки реализации механизмов выгрузки для стороннего решения не считаю корректным....
в своем решении на текущий момент нет информации по сделкам.....
но так как вся инфа по сделкам собирается нашими процедурами, то проблем с ее сбором не будет....
по сделкам с бумагами пока проблема......но это не проблема нашего или стороннего решения....это скорее проблема хранения информации в АБС...
не понял вопрос насчет сбора кредитного портфеля из хранилища..скорее мы его собираем из АБС и отдаем в хранилище....
О!! тогда ясно, что планируется передавать по сделкам.
у вас, видимо, все ведется в АБС - и физики и юрики и бумаги.
Кстати - отладка выгрузки сколько заняла по времени и по ресурсам ?
если говорить о выгрузке для своего решения, то условно 1 чел/мес......но нужно учитывать, что этот чел прекрасно знал, что где лежит и как это брать и куда класть.......
1 человеко месяц - хорошая скорость. У нас контрольные процедуры для загрузки примерно столько времени писались . но мы в движок ЦФТ влезали. т.е. делали автоматический контроль ошибок в передающей среде и догрузку ошибочных данных.
столько продуктов использовать - это конечно "из пушки по воробьям" , но работает. решение расширяемое - но расширять тяжело.Неудобные интерфейсы получились у шлюза. Наш косяк тоже - не смогли вдолбить подрядчику , чего все-таки нужно. Пришлось самим сделать.
s2k2000:
У меня есть реальный опыт внедрения Контура 2.5 на следующих объемах:
счета -- порядка 10 млн, проводки -- до 500 тыс в день, 20 филиалов
Если сделать экстраполяцию ваших объемов то получится 50-150 часов на дневной импорт.
Отсюда простой вывод о том, что либо у вас никто не занимался элементарной оптимизаций, либо программа занимается чем то еще очень умным
насколько я понимаю у вас 1,5 часа уходит на:
1. Импорт карточек клиентов, счетов и курсов валют (если все в порядке до это минута времени на ваших объемах)
2. Импорт проводок. это минут 15 на слабом сервере, минут 7-8 на нормальном
3. Классификация и расчет УБ. Тут все критично зависит от производительности сервера и его грамотной оптимизации. Если все в порядке, то минут 5 все может занять
По идее все должно занимать минут 30, если вы грузите только бухучет и не грузите сделки
Насчет веселья Главбуха, я с вами не соглашусь. я видел не мало главбухов, но никто из них не весельлся в таких случаях. В маленьких банках главбухи в таких случаях вздыхают, а не смеются, так как понимают, что неконтролируемые откаты это зло (имя его - бардак)
а в крупных банках все очень жестко регламентировано: например простые сотрудники могут работать в сегодняшнем дне и вчерашнем. с письменого разрешения зам.глав буха откат на 3 дня. с письменного распоряжения главбуха откат на неделю. и все выполняется достаточно жестко.
to s2k2000:
"А проблема с кучей филиалов, что со своим решением, что со сторонним будет упираться в наличие у банка нормальных специалистов, знающих структуру своей (своих) АБС - потому что разработчик скажет Вам "поставка данных - ваша проблема"...и вы будете все равно ее решать сами....." - вполне логично, что если по условиям контракта разработчик не отвечает за выгрузку и качество данных, то эти задачи будут не совсем его проблемой... Они будут его бедой, т.к. пока Заказчик сам не разберется со своими проблемами в первичном учете и с выгрузкой, то конечного результата не будет. В итоге сроки проекта плывут, результаты не самые радужные, а негатив на разработчика - решение плохое и не дает правильные отчеты... Таким образом, на интеграции и качестве данных нет смысла экономить, а необходимо расширять зону ответственности поставщика/внедренца в решении этой очень важной задачи.