Все про автоматизацию управления и учета для директора

24 июля 2001 г.

архив рассылки

 

Здравствуйте! Сегодня в выпуске:

1. Окончание статьи "Самая главная тема"
2. Практическая рекомендация
3. Мифы

Самая главная тема
(окончание)


Сказанное выше можно сформулировать по другому: Главная проблема подавляющего большинства систем автоматизации и управления для малых предприятий состоит в том, что на документ возлагаются функции его интерпретации в термины предметной области.
Документ (накладная, платежное поручение и т.д.) "сам решает", как он "отображается" на область его использования. Документ сам "проводит" себя в бухгалтерском, налоговом учете. Документ "сам решает", как он влияет на аналитическую отчетность. Если лишить документ этих функций, то многие проблемы просто исчезают.

Пример 1: Различия между коммерческими и бюджетными организациями. Разница между ними в способе построения отчетности. В способе начисления налогов. И не более того. Первичные документы одинаковы. Если бухгалтерский и налоговый учет будут организованы как процедура генерации отчетов над множеством первичных документов, то достаточно подготовить два комплекта программ генерации отчетов: для коммерческих и для бюджетных организаций. Первичные документы и программы манипуляции с ними будут одинаковыми.

Пример 2: Совместные предприятия. На таких предприятиях кроме стандартной отчетности нужно создавать и "иностранную" отчетность для сторон учредителей. Если нагружать этой функцией документы, то ничего хорошего не получится (и не получается!). Сколько вариантов таких систем может быть? Для Российско-Немецких СП. Для Российско-Польских. Для Российско-Немецко-Польских... Возможно ли это? Если просто создать "немецкие", "польские", "румынские" и т.д. программы генерации отчетов, то использовать их можно в произвольной комплектации. И, самое главное, наличие таких программ генерации "национальных" отчетов не затрагивает архитектуру системы. Вообще не затрагивает! Такие комплекты программ могут создать сторонние разработчики, никак не связанные с разработчиками основной системы. Это будут просто отдельные программы, просто использующие базу данных.

Пример 3. Одновременное использование "старых" и "новых" правил предоставления отчетов. Кто мешает последовательно создать комплект отчетности и с помощью старой версии программ, и с помощью новых, не проверенных версий. А это проблема! Я много раз наблюдал ситуацию, когда после обновления программ вернуться на старую версию не представлялось возможным. Обновили, ошибку нашли (не в отчетах, а в основной функциональности), работать нельзя, рады бы вернуться назад, так нет! И формат базы данных изменился и архитектура программы...


Вернемся к теме реализации в системе полного комплекта первичных документов и фиксации причинно-следственных связей между ними. Кроме низведения многих сложностей к банальной процедуре генерации отчетов такой подход позволит решить еще одну очень важную проблему. Проблему контроля. Тотального контроля движения денежных и материальных средств на предприятии.
Эту задачу большинство систем автоматизации для малых предприятий не решают вообще. Рассмотрим опять мой пример с командированием сотрудника. Если фиксация факта такого командирования сводится к выписыванию расходного кассового ордера и проведением последнего, то о каком контроле идет речь? Имел ли вообще бухгалтер право выдавать деньги? А нужно ли было посылать сотрудника в командировку? А отчитался ли сотрудник, сдал ли авансовый отчет? Или все это нужно делать вручную? А зачем тогда все эти дорогостоящие средства автоматизации?
Проблема контроля крайне важна при большом документообороте, при большом количестве перемещений товарно-материальных ценностей. Если не фиксировать в базе данных системы каждый шаг в осуществлении хозяйственных операций, то о контроле можно забыть! В проводко- ориентированных системах полный контроль невозможен!
Попробуйте получить, например, отчет об эффективности использования менеджерами фирмы права на индивидуальные скидки постоянным покупателям. Не используют ли менеджеры это право во вред фирме? Получить эту и подобную ей по важности информацию можно только из первичных документов. Только при условии их полной комплектности. И только при возможности выделения группы документов, реализующих ту или иную хозяйственную операцию.

Можно попробовать взглянуть на затронутую в этой статье тему и с другой стороны. В западных странах распространены так называемые бухгалтерские фирмы. Эти фирмы по договору с клиентами готовят за них всю бухгалтерскую отчетность. И несут ответственность за правильность этой отчетности. Клиент обязан предоставлять такой бухгалтерской фирме ВСЕ первичные документы по мере их рождения. Все эти накладные, счета, заявки, инвентаризационные ведомости, акты распределения прибыли... И на основе этого вороха бумаг бухгалтерская фирма готовит отчетность. И НИКОГО НИ О ЧЕМ НЕ СПРАШИВАЕТ! Вся информация существует в первичных документах. Работа бухгалтерской фирмы сводится к вводу в базу данных всех этих первичных документов и периодическому генерированию отчетов по такой базе данных. Периодичность генерации отчетов определяется требования закона о "непрерывности" ведения бухгалтерского и иных видов учетов. И не более того.
Для многочисленных мелких западных предприятий услуги таких бухгалтерских фирм куда дешевле содержания парка компьютеров и коллектива программистов.
А для любой программы автоматизации учета возможность использования ее бухгалтерской фирмой может служить хорошим тестом. Вряд ли возможен режим, когда по любому поводу нужно будет звонить клиенту и задавать многочисленные вопросы его "всезнающему" человеку.


---

ПРАКТИЧЕСКАЯ РЕКОМЕНДАЦИЯ

Практически всегда разработчики программ декларируют незаурядные возможности своей продукции в части всевозможных видов контроля правильности и законности действий оператора. Называют это красивыми терминами, вроде "внутренний аудит", "контроль правильности" и т.п.
Действительно, программа должна осуществлять контроль действий персонала на предмет соответствия законам. Это, кстати, одна из функций бухгалтера. Причем важная функция! Но полезно убедиться, а действительно ли программа осуществляет хотя бы элементарные проверки. Начать нужно с самого простого и важного.
Создайте приходную накладную (приходный ордер). Затем "проведите" эту накладную "по бухгалтерии". Т.е. сделайте соответствующие проводки на бухгалтерские счета. Но сделать это надо, исходя из предположения, что товары получены "по предоплате" (это значит, что сначала предприятие заплатило деньги, а затем получило товар). Затем создайте платежное поручение, которым осуществлялась оплата за товары, полученные по созданной ранее приходной накладной. Но датировать платежное поручение нужно более поздней датой, чем дата, которой датирована приходная накладная. Если система никоим образом не "выскажется" по поводу этого вопиющего нарушения, то:
- или система вообще не сопоставляет "связанные документы". А это означает, что никакого контроля система вообще не может осуществлять;
- или система "связывает" документы, но просто не осуществляет контроль. Все возлагается на плечи оператора.
Собственно, этот тест заключается в попытке создать и "провести" два документа, фиксирующие одну хозяйственную операцию. При этом документы должны "проводится" неправильно или противоречиво. Будет ли система реагировать на ошибки?
Если дата окончания отчетного периода будет "разделять" такие неправильно проведенные документы, это может вызвать серьезные проблемы при проверке предприятия контролирующими органами. При обильном товарообороте персонал с такими видами контроля справиться не сможет. А программа для того и нужна предприятию, чтобы автоматизировать учет, контроль и управление. Во всяком случае, такую несуразицу программа должна фиксировать! Ну не может "предоплата" быть позже получения товара!
Более того, если документы (в нашем случае приходная накладная и соответствующее ей платежное поручение) "связываются" друг с другом, то зачем вообще позволять персоналу выбирать очевидное. Зачем вообще система в нашем случае требует указания "предоплата" или "пост оплата". Что, программа сама не может "сообразить" этого, исходя из анализа дат документов?
Можно многое узнать о предлагаемой программе, просто послушав комментарии разработчика или продавца о поведении программы в условиях предложенного теста.



---

МИФЫ


Миф №3

Я уже говорил о том, что законодатели, вопреки распространенному убеждению, очень редко "привносят" в документооборот новые первичные документы. Но существует еще миф о том, что существующие первичные документы часто модифицируются законодателями.
Берем лист бумаги. Пишем заголовок: "Перечень первичных документов, формат (правила создания) которых были изменены законодателями за последний год (последние два-три... года"
1...
2...
3...
....

Сколько строк удалось заполнить? Можно ли утверждать, что законодатели часто изменяют первичные документы?



Миф №4


Продавцы программ практически всегда обосновывают необходимость дополнительных доработок, а значит и дополнительных оплат, якобы уникальной природой предприятия заказчика. В ход идут термины о "специфике предприятия", об "управленческом ноу-хау", существующем на предприятии и т.д. Как правило, это просто лесть. А любая лесть не бескорыстна. Сначала директору рассказывают о том, что его предприятие предельно нестандартно, самобытно и вообще таких фирм в мире единицы, а затем подсовывают счет...
Но сколько существует оптовых и розничных торговцев, строительных фирм, аптек, заводов по производству пищевых продуктов, сельскохозяйственных предприятий...? Сколько вокруг таких фирм как ваша? Я могу согласиться, что крупный машиностроительный завод, металлургический комбинат и т.п. есть предприятия уникальные и самобытные. Но конкретно ваше предприятие такое? Или Дума приняла закон о том, что только для вашего предприятия налоги рассчитываются особым образом? Или только вы торгуете фармацевтической продукцией, и, стало быть, только вас затрагивают законодательные вариации для этой сферы деятельности?
Берем лист бумаги. Пишем заголовок: "Причины, по которым можно считать мое предприятие уникальным и специфичным"
1...
2...
3...
....
Много набралось таких причин?
Может "учет специфики" есть просто исправление недоделок?
Или то, что вам предлагают оплатить дополнительно, в законодательстве не отражено?
А как тогда быть с декларациями разработчика "о полном учете законодательства"?
Или таких деклараций разработчик не делает?


---

Олег Сиголов
sigolov@yahoo.com

 

Допустимо любое использование материалов данной рассылки  с указанием источника!