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