|
Большое спасибо за интерес, проявленный к теме.
Перед тем, как отвечать на вопросы позволю себе маленький экскурс, который частично ответит на вопросы и объяснит причину, почему я не стал упираться в изучение и разработку на имеющихся системах.
В двух словах ситуация такова. Я - финансовый аналитик в небольшой судоходной компании. В 2004 году авторизованным представителем в нашем городе, было установлено решение на Навижн 3.60 для организации управленческого учета. Именно не бухгалтерского, а управленческого. Для бухгалтерии и официальной отчестности до сих пор используется 7.7. Когда я пришел на работу Навижн уже использовался почти год. Когда въехал в систему - обнаружилась масса косяков и недоработок, из-за которых руководство весь предыдущий год получало неверную отчетную информацию. Был скандал. Более того. То решение, которое было реализовано, мягко говоря не удовлетворяло главному принципу - дружественность интерфейса. Т.е. грубо говоря, начальники отделов сказали - "Мы вам че, бухгалтера чтоль, разбираться про какие-то измерения и финсчета, идите в баню, как писали на бумажках да в Ворде, так и будем". В результате получили, что все первичка вносилась несколькими сотрудниками, далекими от специфики привычной документации, что привело к неизбежным задержкам по внесению, постоянным ошибкам при внесении, а из-за реализации в Навижне корректировка ошибок стала ваще страшным сном вносящих (ситуация корректировки на корректироку корректировки - стала вовсе не анекдотом, а моим кошмаром). Любые техзадания по доработке стали утыкаться в сроки и стоимость. Причем объем выполняемых работ мягко говоря не соответствовал цене, ну дорого блин Навижн обходится. С горем пополам за год доведя систему до более менее сносного состояния для нормального учета, настроив новую базу на Навижн запустил новую читую конфигурацию, но все равно, проблемы указанные выше чуть уменьшились, но никуда не делись. Все необходимые финансовые модули, которые были необходимы для получения комплексной отчетности писались на Access нашим программером, либо просто были представлены несколькими таблицами Excel, итоговые данные которых попадали в Навижн как учетную систему. Короче бардак. Когда возникла задача по автоматизации материального учета предприятия, решили для этой задачи попробовать 1С. Получилось достаточно быстро, эффективно. Делали на 8-ке. Но возникли проблемы: Скорость обработки больших объемов, опять же проблема, что совсем небольшие доработки интерфейсов требовали значительного времени, более менее сложные доработки - много времени. И снова ошибки, снова сроки доработок, стоимость... И главное - нормальная автоматизация (для меня нормальная - это когда продукт используется всеми сторудниками и им этот продукт помогает в работе, а не создает дополнительные головняки) - так и не была достигнута. При этом я для своих задач отчетности использовал набор Excel таблиц организованных по принципу OLAP, и очень скоро пришел к выводу, что для решения задачи оперативной отчестности и автоматизации учета достаточно просто создать систему по автоматизации того, что я делал вручную. Что и сделал.
По сути моя система - автоматизация заполнения докуметов, сформированных на Excel таблицах в рамках существующей на предприятии отчетности. На текущий момент все данные хранятся в двух сервисных таблицах и в наборе таблиц, который соответствует принципу: один первичный документ - одна таблица. Показанный скриншоте документ - компленксный, т.е. один документ - набор нескольких взаимосвязанных.
Теперь по порядку:
РеалистInfinity Creator,
Зачем тратить кучу сил и времени, что бы написать "свое крутое с нуля", вместо того, что бы взять Open Source систему и "заточить" под себя?
Дело не в попытке написать нечто "крутое". Дело в тех сложностях, с которыми я столкнулся и описал выше. И еще. Я пока не встречал систем, в которых можно было бы ввести новое рабочее место буквально следующим образом: например место кассира, который ведет кассу предприятия. Садимся рядом с кассиром, у него на глазах в листе Excel рисуем приходник, расходник, спрашиваем что куда удобней разместить, поля, таблицы и пр. После этого на 20 миунт посылаем кассира передохнут. Имея на руках правила внесения данных в кассовый отчет в течение 15 (максимум) минут вносим в системные таблицы документа правила взаимодействия полей и документа с регистром движений. Я не преувеличиваю по скорости, я решая эту задачу именно такую цель и преследовал - автоматизация без программирования насколько возможно. Так вот, через 20 минут приглашаем кассира, прсим поделать проводки (на этот момент интерфейс подключен к тестовой таблице на сервере). После того, как сотрудник на 30-60 минут осваивается, по ходу просит подправить что-то, даже возможно добавить поля какие-то, в системном интерфейсе прописывается имя рабочего регистра документа - и все. Рабочее место подключено. Причем даже после подключения можно спокойно по ходу добавлять новые поля (шапочные, табличные - без разницы), тут же описывать правила их заполнения и включать в дальнейшую работу. Все написанное не теория - реальная работающая практика. И главное. Базовый язык - VBA. Толковый программер VBA - дешевле и чаще программера 1C или тем более Навижна. Любой Open Source требует специфичного специалиста. Моя система - для просто грамотного программера, потому что код я сразу старался делать практически самодокументированным с именами структур типа RulesTable.DocumentRules(Doc).Condition(Rule).SlaveCondition(j).
Преследовалась основная цель - чтобы стоимость найма нового программиста для сопровождения системы была минимальной при этом не страдало качество самого продукта и его сопровождения.
СергейТТТInfinity Creator,
А чем именно не устроил 1С и Навижн ?
Выше я немного ответил на этот вопрос. Могу добавить, что времени на изучения этих сред - нет. А я столкнулся с острой необходимостью частой доработки отчестности, появлением новой, новых рабочих мест и т.п. Обе системы решают задачу быстрой качественной перестройки структурных изменений первичной документации крайне болезненно, неповоротливо и дорого. Возможно это от программеров зависит, но практика показала этот минус, как очень существенный. Решение на VBA - универсально и просто.
LSVИнтерфейс немного унылый. Кнопки не должны быть разбросаны по форме и быть разных размеров.
Почему использованы иконки Экселя ?
Кнопка "Провести" безграмотна, т.к. в общем случае у документа может быть много разных статусов.
А если нужно его отсторнировать/аннулировать ?
сомневаюсь, что удалось очень элегантно сделать гибкий интерфейс без программирования.
КОНСТРУКТОРЫ БИЗНЕС-МОДЕЛИРОВАНИЯ - Утопия и попса, не решающая задачу. Нюансов может быть столько, что никакой конструктор не выдержит. Делать же полу- и недоконструктор нет смысла.
Какя СУБД и где лежит логика вычислений ?
Унылость - тут дело вкуса. При желании - хоть бабочек анимированных вместо кнопок пофтыкать можно. Потому что для интерфейсных решений используеться весь мощнейший арсенал средств Excel.
Кнопка "Провести" - текущее решение в рамках имеющейся задачи. Не забывайте - система, которая все еще в стадии разработки уже 2 месяца гонит первичку по самому сложному на предприятии отчету и я уже использую для отчетности аналитику из этих данных.
Гибкость интерфейса. Основной принцип, заложенный в работу интерфейса - взаимосвязь полей в реальности. Т.е. если такие-то поля документа заполнены такими-то данными, то другие заполняются так-то и так-то с применением фильтров, формул и других документов. Эти взаимосвязи прописываются в системную таблицу интерфейса, ну например вот скрин куска системной таблицы:
http://www.zmx.ru/Infinity2.jpg
На текущий момент используя этот принцип удалось не используя программирование автоматизировать внесение всей первички на предприятии.
Субд - SQL Server 2000. А вот с логикой сложнее и проще. Логика - прописана в таблицах правил каждого документа и интерфейса. На текущий момент для автоматизации ввода первичной информации потребовалось разработать 2 системы правил - правила взаимодействия полей и правила двойной записи. Далее последуют правила взаимодействия интерфейсов в рамках организованных и прописанных бизнес процессов. Используется несколько принципов, которые сам придумал. Возможно изобрел велосипед, но мне от этого ни холодно ни жарко. Мне результат важен. А он имеет место быть.
А вот по поводу конструктора не соглашусь. Все зависит от того, какой принцип вы изначально будете закладывать в конструктор, от каких абстракций будете отталкиваться. У меня есть идеи на этот счет, но покав это не реализованная практика - говорить об этом рано.
GaryaДополню свое высказывание.
Вопрос "сколько может стоить?" нужно задавать не технарям-специалистам, а тугим кошелькам, бизнес-менам. Сколько бизнес-мен захочет выложить денег за... а вот за что? Какие аргументы Вы приводите? Насколько заманчива для бизнес-мена , использующему всего 2-3 учетные единицы в своем бизнесе возможность иметь неограниченное количество учетных единиц? Вы приводите информацию о глубоко специфических технических нюансах технарям, которые из своего кармана не собираются ни за что платить.
Для людей же бизнеса технические нюансы интересны постольку-поскольку. Они больше обращают внимание на опыт внедрений - покажите, где вы это уже внедрили, мы спросим, довольны там люди или нет (отсюда и возникает порог вохождения - у новичка никто не захочет покупать , даже забесплатно - риск может оказаться дороже бесплатности). Бизнесмена интересуют риски, выгоды, которые он получит, сроки, деньги. Возможности решить какие-то бизнес-задачи, которые без этого продукта он решить не может. В частности, если бизнес-мен узнает, что продукт разрабатывается одним человеком, он, если не дурак, тут же откажется брать его даже за "спасибо". Почему? А что он будет делать с этим продуктом, если единственный разработчик внезапно попадет под трамвай?
И еще. Сейчас - мировой кризис. Все предприятия резко сокращают инвестиции. В существенной степени это касается инвестиций в IT. В условиях кризиса затевать новые инвестиционные бизнес-проекты по меньшей мере странно. Те же 1С и Навижн, уже имея весьма обшируню аудиторию, в условиях кризиса начнут демпинговать, пытаться найти иные методы соблазнения клиентов... Вы полагаете, что обнаружив на горизонте конкурента они не смогут его раздавить? Какие аргументы приводит конурент? Неограниченное количество измерений? Слегка-слегка поднапрягутся, и выпустят новую версию с неограниченным числом измерений. И что дальше? Что будет с Вашими преимуществами?
Как я уже говорил выше, именно по причине необходимости сокращения издержек я и стал точить свой продукт на самой широко распространенной платформе - на MS Office + VBA + SQL Server. Именно потому и код программный писал с трехэтажными названиями переменных и процедур - чтобы потом любой даже средний программист мог въехать в логику при минимальных объяснениях кода. Потому что я реалист, и понимаю, что ВСЕХ задач без кодирования не решить. Но основные, требуемые для качественного учета первичной информации и ее обработки - решаются при помощи правил, которые, кстати, можно как угодно менять в процессе работы, что тоже дает очень большую гибкость.
По поводу внедрений. Сейчас система активно внедряется и уже работает в судоходной компании. Судоходный бизнес - вы мне поверьте - очень непростой в сравнении с традиционными. Хотя и в традиционных заморочек хватает. Так вот, мне кажется опыт внедрения на таком предприяти даст неплохой вес.
А что могут поднапрячся... У них идеология работает по другому. Они сразу начинают лепит килотоннами реляционные таблицы, в которых чем больше предприятие, тем меньше и меньше людей могут видеть общую структуру и тем дороже и дороже становится содержание таких специалистов для поддержания работоспособности системы. А это, на мой взгляд - глюк. Программа должна облегчать жизнь сотрудникам и предприятию, а не делать компанию заложником группки узкоспециализированных высокооплачиваемых кадров. Структура моей системы, после объяснения ее принципов, стновится понятна даже неспециалисту в базах данных. Проверено на жене :)
Ну и последний момент. Система разработана мной с нуля до текущего состояния за 4 месяца. Мне кажется - это показатель эффективности заложенной в систему идеи.
|
