Компьютер в бухгалтерском учете и аудите 1999'2
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Компания “Светон”

Автоматизация крупного бизнеса — вопросы
и решения

В предыдущих номерах журнала мы рассказали о корпоративной системе управления торгово-производственными предприятиями “Дельфин”. Обзор был посвящён в основном функциональным возможностям программы.

В этой статье хотелось бы остановиться на вопросах, возникающих у представителей предприятий при выборе систем такого уровня, и привлечь внимание скорее системных администраторов, чем рядовых пользователей.

Любое предприятие, и особенно крупное,— это живой организм со своими требованиями и идеологией построения схем организации и ведения бизнеса. И зачастую эта идеология не совпадает с бизнес-логикой, заложенной в программы разработчиками. Давайте попробуем разобраться в основных вопросах, возникающих при выборе систем, а также проанализировать решения, предлагаемые разработчиками корпоративной системы “Дельфин”.

Очень важным с нашей точки зрения является вопрос, насколько точно и корректно система отображает события, происходящие в бизнесе.

Если в системе одни физические явления подменяются другими (например, объявляется, что приход товара эквивалентен составлению приходной накладной) — это тревожный сигнал. Рано или поздно Вам может понадобиться отдельно отразить приход товара и, например, составление нескольких приходных и возвратных накладных, связанных с этим приходом, — и Вы не сможете этого сделать. Чем больше то, что происходит в системе, похоже на реальную жизнь — тем лучше.

Подавляющее большинство из представленных на рынке компьютерных систем того же класса, что и “Дельфин”, основаны на бухгалтерских методах учёта. Это связано с тем, что программисты, писавшие их, информацию о практике торговли получали от консультантов — а это в основном были бухгалтеры. Однако бухгалтерия имеет свой вполне конкретный метод и решает вполне определенные задачи, которые не полностью охватывают практические вопросы, с которыми сталкивается предприятие в ходе своей деятельности. Формализованный бухгалтерскими правилами учет по принципу “от документа” не позволяет точно описывать некоторые события, происходящие в жизни.

Бухгалтерский метод учета вводит некоторые условности, игнорирует временные промежутки, проходящие между самим событием и внесением учетных данных о нем в реестры. Эти небольшие допущения могут вызывать существенные ошибки в системах со сложными связями. Например, после приемки, составления и подписания приходной накладной и назначения цен, товар отправлен в торговый зал. Начались продажи, но данные в компьютер еще не внесены. Система дает ошибки в закупочной цене, хотя с точки зрения правил торговли все было сделано верно. Эту проблему можно решать организационными методами — не пускать товар в продажу, пока не внесены все данные в компьютер. Но в общем случае это означает задержки в процессе торговли, а следовательно — потери. К сожалению, большинство доступных программ вынуждают прибегать именно к организационным методам корректировки учета. Более того, многие из них запрещают работать гибко. Например, свойственное большинству таких систем отсутствие возможности “внесения изменений задним числом”, что нормально для бухгалтерии, делает систему абсолютно не применимой в условиях, когда с системой работают десятки людей самой различной квалификации. При этом часто совершаются ошибки при вводе данных, исправлять которые бывает необходимо по мере обнаружения, через много дней после того, как они были совершены.

Одной из важнейших особенностей системы “Дельфин”— то, что она может описывать приведенные выше “трудные” случаи и избавляет от необходимости применения “условных” учетных действий или организационных мер. Такие возможности “Дельфин” имеет благодаря тому, что основой учета считает событие (хозяйственную операцию), а не документ, составленный по итогам события.

Ещё ряд немаловажных вопросов.

Когда разработана система? Под управлением какой операционной системы она работает? Какая система управления базами данных используется?

Функциональные возможности СУБД, используемых в системе, должна соответствовать масштабам предприятия. Для предприятия, имеющего тысячи наименований товаров и достаточно развитую компьютерную сеть, необходимо использовать современные, достаточно мощные и надёжные системы, такие как MS SQL Server, Oracle и так далее (в зависимости от финансовых возможностей покупателя ПО).

“Дельфин” построен в двухзвенной архитектуре клиент/сервер (Delphi/MS SQL Server). Структура исходных данных построена в полном соответствии с теорией реляционных баз данных: соответствует нормальной форме 3N, поддерживает ссылочную целостность, в операционном режиме полностью исключает избыточные данные. “Дельфин” в полной мере использует преимущества архитектуры клиент/сервер: вся бизнес-логика, обработка данных, обеспечение целостности данных, разграничение прав доступа к объектам базы сосредоточены на сервере. Клиентское приложение занимается исключительно интерфейсом пользователя и не занимается данными. Для достижения максимальной производительности, как в операционном, так и в аналитическом режимах эксплуатации применяется метод разделения системы на OLTP сервер и OLAP сервер. Для синхронизации данных применяется однонаправленная схема репликации, в которой новые данные и изменения существующих периодически переносятся из OLTP сервера на OLAP сервер. Структура индексов, наличие избыточных данных, настройки сервера и разрешённые пользователям запросы различны на каждом из серверов и позволяют решать задачи как транзакционной, так и аналитической обработки с наивысшей производительностью. Благодаря применению Delphi в качестве средства разработки клиентское приложение системы Дельфин обладает высокими потребительскими качествами интерфейса пользователя, что создаёт комфортные условия для работы сотрудников организации.

Следующий вопрос скорее риторический, но, тем не менее,— какой должен быть в системе интерфейс?

Конечно, нужно, чтобы клиентская часть программного продукта имела Windows-интерфейс. Не надо верить рассказам, что не привыкшим к компьютеру работникам легче работать с “простым” DOS-интерфейсом.

Windows-интерфейс — это не просто вопрос удобства. Он решает две очень важные практические задачи. Во-первых, снижается количество ошибок при вводе данных и ускоряется работа операторов — это прямая экономия денег. Во-вторых, графический интерфейс позволяет руководящему персоналу предприятия получить возможность прямого общения с данными, без посредников в виде системных администраторов и программистов. Можно быть уверенным, что ни у одного генерального директора нет времени разбираться, когда ему надо нажимать Alt-F1, а когда Ctrl-Z. В то же время многие управляющие среднего и верхнего звена владеют Word и Excel, а значит, разберутся в любом графическом интерфейсе быстро и легко.

Поэтому в системе “Дельфин” полностью реализован Windows-интерфейс (например, возможность перетаскивать объекты, отображать графические изображения (рис. 1 и рис. 2) и многое другое), что оправдывает термин “дружественный”.

Рис.1

Рис.2

Следующий вопрос, исходя из специфики организации учётов, интересует практически всех, а именно, позволяет ли система изменять или дополнять ее штатные функции?

Необходимо, чтобы персонал, администрирующий систему на предприятии, имел возможность доступа к данным системы на низком уровне. Для этого необходимы два условия: поставщик программного обеспечения должен предоставлять структуру базы данных своего продукта и способ доступа к данным должен осуществляться с помощью широко распространенного языка программирования.

Дело в том, что в ходе эксплуатации неизбежно возникнет необходимость делать операции, не предусмотренные штатным функционалом системы. Некоторые программные продукты имеют собственный встроенный язык (например, программы, написанные на базе менеджера записей Btrieve). Это облегчает работу, но требует программистов, специально обученных программированию на этом языке и, что еще хуже, — делает затруднительным оптимизацию запросов с точки зрения скорости и эффективности выполнения. Гораздо лучше, если доступ к базе данных осуществляется на одном из диалектов SQL, а клиентское приложение написано на одном из широко распространенных универсальных языков программирования,— например, Object Pascal. В этом случае не будет проблемой найти квалифицированных программистов, которые смогут адаптировать систему к меняющимся потребностям предприятия. Тогда организация, использующая программный продукт, не будет находиться в постоянной зависимости от поставщика ПО. А это означает, по меньшей мере, существенную экономию средств.

Остановимся более подробно на следующем вопросе.

Как будет реагировать система, если Вам понадобится внести изменения в прошедшем времени? Например, исправить ошибку, допущенную оператором при вводе данных из приходной накладной месяц назад, когда товар, пришедший по этой накладной, уже перемещался по складам предприятия, продавался и так далее

Такие ошибки будут возникать обязательно. Это — самая сложная проблема, с которой на практике очень часто сталкиваются торговые предприятия.

Вариантов ответа на этот вопрос может быть как минимум три. Первый — система не позволит Вам это сделать. Тупиковая ситуация. Однако многие программы работают именно так. Второй — система даст вам возможность это сделать, но не исправит другие связанные данные. Это лучше, но в этом случае для сохранения согласованности и непротиворечивости данных надо предпринимать организационные меры, чтобы при каждом изменении данных в прошлом тщательно проверять и исправлять все вторичные данные. На практике это приводит к путанице и недостоверности отчетов. Лучше всего третий вариант,— когда система построена так, что она позволяет вносить изменения в прошлом, но при этом предоставляет эффективные средства для сохранения согласованности первичных и вторичных данных. Такая идеология — большая редкость на нашем рынке и именно её придерживается система “Дельфин”.

Как система обрабатывает платежи и различные виды взаимоотношений, которые возникают с поставщиками и клиентами?

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

При этом нужно, чтобы система была достаточно проста и соответствовала действительности. Например, когда система сразу при фиксировании операции (например, продажи) “накручивает” на нее серию вспомогательных действий, включая бухгалтерские проводки, результат получается негативным. Накапливаются вторичные данные, система становится сложной в настройках и эксплуатации.

Лучше, чтобы та часть системы, которая обрабатывает движение товара и средств, формировала и систематизировала данные, а превращением данных в бухгалтерский “формат” занимался отдельный модуль, специально разработанный как бухгалтерская программа и играющий роль своеобразного редактора.

Где используется и как зарекомендовала себя программа?

Как бы внимательно Вы ни изучали систему, ее подводные камни проявятся только при эксплуатации. Нужно попросить предоставить список предприятий, где внедрена система, проконсультироваться о сильных сторонах системы и проблемах, с которыми сталкивались пользователи. Если есть возможность, полезно переговорить с конкурентами поставщика.

Что касается системы “Дельфин”, то после выставки SofTool’98 компания “Светон” подписала контракт на внедрение системы в одном из крупнейших торговых предприятий Москвы — супермаркете “Твой Дом”. Масштабы этого предприятия впечатляют: одновременно в торговом зале площадью 16000 кв.м. выставлено около 50000 видов товара. Одновременно торговый комплекс обслуживает как розничных, так и оптовых покупателей. В процессе внедрения практика показала, что система с успехом справляется со всеми технологическими операциями, обрабатывая и анализируя их нужным для пользователей образом. Большие объёмы обрабатываемых данных также не сказались на быстродействии системы в целом.

Рис.3

И в заключении хотелось бы остановиться на вопросе чисто организационного характера.

Как поставщик собирается адаптировать программу под потребности Вашего предприятия и как он будет ее внедрять?

Если эти два эт