Электронные курсы > Как выбрать программу для автоматизации бюджетирования и управленческого учета > Часть 2. СУБД и ввод данных в систему
Рис. 1. Укрупненная архитектура информационной системы
Как правило, эта внешняя оболочка очень активно использует возможности СУБД. Причем в современных СУБД есть очень много полезных функций, использование которых позволяет достаточно эффективно управлять информацией, хранящейся в базе данных.
Кстати, скорость вычислений и построения отчетов зависит не только от тех алгоритмов, которые зашиты в программном продукте (оболочке), но и от тех алгоритмов, которые используются в СУБД.
Естественно, что еще одним фактором, существенно влияющим на скорость вычислений, является сервер (его технические характеристики), на котором будет установлена СУБД. Этот же фактор влияет и на стоимость проекта по автоматизации бюджетирования и управленческого учета.
В общем, при выборе программного продукта для бюджетирования и управленческого учета (впрочем, как и любой другой программы) нужно обращать внимание не только на внешнюю оболочку, но и на используемую СУБД.
Кстати, когда компания покупает программный продукт, нужно учитывать, что чаще всего объявленная стоимость программы – это только стоимость той самой оболочки. В общем-то, в этом нет никакого обмана со стороны тех компаний, которые продают программные продукты.
Ведь они действительно продают именно свои (или чужие) разработки. А что касается СУБД, то она либо уже должна быть куплена клиентом, либо эту операцию еще предстоит сделать.
Можно долго спорить о том, какая из этих СУБД лучше, – только этот спор будет очень похожим на выяснение того, с какого конца правильно разбивать яйцо: с тупого или с острого.
Хотя если говорить о статистике, то СУБД компании ORACLE в основном пользуются очень крупные компании. А СУБД компании MicroSoft используют предприятия меньшего масштаба. На самом деле данное решение подходит и для крупного бизнеса, просто исторически ORACLE раньше вышла на этот рынок, чем MicroSoft.
Итак, при выборе программного продукта нужно обращать внимание не только на сам продукт и на его возможности развития в перспективе, но и на то, с какой СУБД он работает. Даже если сам продукт будет постоянно развиваться, но работать он будет с какой-то старой и неперспективной СУБД, то со временем возможности такой системы будут значительно уступать своим аналогам, работающим с более эффективной СУБД.
При этом нужно четко понимать, что даже применение самой современной и продвинутой СУБД вовсе не гарантирует того, что в программном продукте, использующем данную СУБД, действительно реализован многопользовательский режим работы.
Естественно, что практически все современные производители софта утверждают, что в их программном продукте такой режим реализован. Проверить это на самом деле не так уж сложно. Для проверки нужно выбрать отчет, который считается достаточно долго (из-за большого количества запросов и/или большого количества записей, которые нужно обработать).
Для эксперимента вполне подойдет отчет, на формирование которого у программного продукта уходит около минуты или более того. Этот отчет нужно одновременно запустить хотя бы с двух компьютеров, а еще лучше с трех или даже с десяти.
Желательно нажать клавиши запуска формирования отчета одновременно, хотя если он строится около минуты, то разница в несколько секунд несущественна.
Так вот, если в программном продукте действительно реализован многопользовательский режим работы, то через положенное время на всех компьютерах будет правильный и одинаковый результат в виде определенного управленческого отчета.
Если же многопользовательский режим работы не реализован, то возможно два варианта. В первом случае отчеты будут рассчитаны на каждом компьютере, но результат будет неправильный и на каждом компьютере разный. При втором варианте результата вообще не будет – программа просто зависнет на всех компьютерах.
При этом можно сделать следующие выводы. В первой ситуации разработчики программного продукта даже не пытались реализовать режим многопользовательской работы. Во втором случае такая попытка была сделана, но реализована неудачно.
Компьютеры зависают потому, что каждый из них в момент вычислений запрещает всем остальным делать записи в таблицы, используемые для расчета отчета. То есть возникает так называемая взаимная блокировка.
На самом деле разработчики софта прекрасно знают возможности своих программных продуктов. И они знают о том, что вероятность возникновения такой проблемной ситуации очень мала.
Естественно, чем больше пользователей работают с одной и той же базой данных, тем больше вероятность возникновения ситуации, когда два или более пользователя запустят один и тот же отчет в одно и то же время.
Но все равно вероятность этого события очень незначительна. А если она и возникнет, то всегда можно сослаться на то, что глючит операционная система или используемая СУБД. То есть можно сослаться либо на разработчиков операционной системы, либо СУБД.
Поэтому почти все создатели софта так смело и заявляют о том, что в их программном продукте реализован режим многопользовательской работы.
Несмотря на то, что вероятность таких событий крайне мала, как говориться, по закону подлости может получиться так, что директору распечатают отчет после такой ошибки, или директор сам запустит отчет (если он тоже является пользователем программного продукта) одновременно с другим пользователем.
Естественно, что при этом директор не будет ничего слушать по поводу глюков программы. Виновным будет тот, кто предоставил отчет в бумажном виде (если директор сам не пользуется программой) или делал настройки в программе (если директор – пользователь программы). Поэтому при выборе программного продукта все-таки желательно обратить внимание на данный аспект.
Ведь продемонстрировать это не составляет большого труда. Главное – попросить разработчиков показать, как составляется какой-нибудь достаточно сложный отчет. Его то и можно будет использовать для проверки.
В перечень функций программного продукта, используемого для автоматизации бюджетирования и управленческого учета (на стадии ввода фактических данных), должны обязательно входить следующие позиции: создание новых справочников;
настройка плана счетов;
ввод типовых операций;
импорт данных из бухгалтерских программ.
Примечание: что касается ввода плановых данных, то главное, чтобы система позволяла заполнять строки ввода (те показатели, которые планируются экспертно) и настраивать формулы (устанавливать математические связи между различными бюджетными показателями). Более подробно об этом будет рассказано в разделе "Мастер (конструктор) настройки модели" данного электронного курса.
Ниже представлена форма для подписки на новые материалы сайта (статьи, записи в блоге и опыт), связанные с постановкой системы бюджетирования и управленческого учета. То есть в рассылках будет информация только о новых материалах, аналогичных тому, что размещен на данной странице сайта.
Часть 2. СУБД и ввод данных в систему
Система управления базой данных (СУБД) и многопользовательский режим работы
Кстати, скорость вычислений и построения отчетов зависит не только от тех алгоритмов, которые зашиты в программном продукте (оболочке), но и от тех алгоритмов, которые используются в СУБД.
Естественно, что еще одним фактором, существенно влияющим на скорость вычислений, является сервер (его технические характеристики), на котором будет установлена СУБД. Этот же фактор влияет и на стоимость проекта по автоматизации бюджетирования и управленческого учета.
В общем, при выборе программного продукта для бюджетирования и управленческого учета (впрочем, как и любой другой программы) нужно обращать внимание не только на внешнюю оболочку, но и на используемую СУБД.
Кстати, когда компания покупает программный продукт, нужно учитывать, что чаще всего объявленная стоимость программы – это только стоимость той самой оболочки. В общем-то, в этом нет никакого обмана со стороны тех компаний, которые продают программные продукты.
Ведь они действительно продают именно свои (или чужие) разработки. А что касается СУБД, то она либо уже должна быть куплена клиентом, либо эту операцию еще предстоит сделать.
|
Если говорить о конкретных СУБД, то сейчас на рынке (причем в общемировом масштабе) наиболее распространенными являются разработки компании ORACLE и MicroSoft. |
Хотя если говорить о статистике, то СУБД компании ORACLE в основном пользуются очень крупные компании. А СУБД компании MicroSoft используют предприятия меньшего масштаба. На самом деле данное решение подходит и для крупного бизнеса, просто исторически ORACLE раньше вышла на этот рынок, чем MicroSoft.
Итак, при выборе программного продукта нужно обращать внимание не только на сам продукт и на его возможности развития в перспективе, но и на то, с какой СУБД он работает. Даже если сам продукт будет постоянно развиваться, но работать он будет с какой-то старой и неперспективной СУБД, то со временем возможности такой системы будут значительно уступать своим аналогам, работающим с более эффективной СУБД.
При этом нужно четко понимать, что даже применение самой современной и продвинутой СУБД вовсе не гарантирует того, что в программном продукте, использующем данную СУБД, действительно реализован многопользовательский режим работы.
Естественно, что практически все современные производители софта утверждают, что в их программном продукте такой режим реализован. Проверить это на самом деле не так уж сложно. Для проверки нужно выбрать отчет, который считается достаточно долго (из-за большого количества запросов и/или большого количества записей, которые нужно обработать).
Для эксперимента вполне подойдет отчет, на формирование которого у программного продукта уходит около минуты или более того. Этот отчет нужно одновременно запустить хотя бы с двух компьютеров, а еще лучше с трех или даже с десяти.
Желательно нажать клавиши запуска формирования отчета одновременно, хотя если он строится около минуты, то разница в несколько секунд несущественна.
Так вот, если в программном продукте действительно реализован многопользовательский режим работы, то через положенное время на всех компьютерах будет правильный и одинаковый результат в виде определенного управленческого отчета.
Если же многопользовательский режим работы не реализован, то возможно два варианта. В первом случае отчеты будут рассчитаны на каждом компьютере, но результат будет неправильный и на каждом компьютере разный. При втором варианте результата вообще не будет – программа просто зависнет на всех компьютерах.
При этом можно сделать следующие выводы. В первой ситуации разработчики программного продукта даже не пытались реализовать режим многопользовательской работы. Во втором случае такая попытка была сделана, но реализована неудачно.
Компьютеры зависают потому, что каждый из них в момент вычислений запрещает всем остальным делать записи в таблицы, используемые для расчета отчета. То есть возникает так называемая взаимная блокировка.
На самом деле разработчики софта прекрасно знают возможности своих программных продуктов. И они знают о том, что вероятность возникновения такой проблемной ситуации очень мала.
Естественно, чем больше пользователей работают с одной и той же базой данных, тем больше вероятность возникновения ситуации, когда два или более пользователя запустят один и тот же отчет в одно и то же время.
Но все равно вероятность этого события очень незначительна. А если она и возникнет, то всегда можно сослаться на то, что глючит операционная система или используемая СУБД. То есть можно сослаться либо на разработчиков операционной системы, либо СУБД.
Поэтому почти все создатели софта так смело и заявляют о том, что в их программном продукте реализован режим многопользовательской работы.
Несмотря на то, что вероятность таких событий крайне мала, как говориться, по закону подлости может получиться так, что директору распечатают отчет после такой ошибки, или директор сам запустит отчет (если он тоже является пользователем программного продукта) одновременно с другим пользователем.
Естественно, что при этом директор не будет ничего слушать по поводу глюков программы. Виновным будет тот, кто предоставил отчет в бумажном виде (если директор сам не пользуется программой) или делал настройки в программе (если директор – пользователь программы). Поэтому при выборе программного продукта все-таки желательно обратить внимание на данный аспект.
|
Кстати, отсутствие реального многопользовательского режима работы можно использовать в качестве аргумента снижения цены при заключении контракта с разработчиком (или продавцом) программного продукта. |
Ввод данных в систему
В перечень функций программного продукта, используемого для автоматизации бюджетирования и управленческого учета (на стадии ввода фактических данных), должны обязательно входить следующие позиции:
|
Книгу можно скачать здесь. |
|
Если у Вас возникли какие-то вопросы по данному курсу Вы можете направить их по адресу budgeting@bk.ru. Ответы на Ваши вопросы будут направлены в течение нескольких дней с момента получения. Кроме того по адресу budgeting@bk.ru Вы можете направлять свои предложения по улучшению и возможному дальнейшему развитию раздела "Электронные курсы по бюджетированию и управленческому учету". |
Ниже представлена форма для подписки на новые материалы сайта (статьи, записи в блоге и опыт), связанные с постановкой системы бюджетирования и управленческого учета. То есть в рассылках будет информация только о новых материалах, аналогичных тому, что размещен на данной странице сайта.
