б) Прикладные (пользовательские) программы - это наборы машинных команд для решения пользовательских задач, которые организация-пользователь разрабатывает самостоятельно или приобретает у внешнего поставщика.
3. Документация - описание системы и структуры управления (ввод, обработка и вывод данных, обработка сообщений, управляющие команды).
4. Персонал - работники, которые управляют системой, проектируют ее и снабжают программами, эксплуатируют и контролируют систему обработки данных.
5. Данные - необходимая информация, которую вводят, хранят и обрабатывают в системе (например, сведения о хозяйственных операциях).
6. Процедуры контроля - в разрезе учета это процедуры, обеспечивающие корректную запись операций, предупреждающие или регистрирующие ошибки. Способ обработки хозяйственных операций при ведении бухгалтерского учета оказывает существенное влияние на организационную структуру фирмы, а также на процедуры и методы внутреннего контроля. Компьютерная технология характеризуется рядом особенностей, которые следует учитывать при оценке условий и процедур контроля. Ниже приведены отличия компьютерной обработки данных от неавтоматизированной. Единообразное выполнение операций. Компьютерная обработка предполагает использование одних и тех же команд при выполнении идентичных операций бухгалтерского учета, что практически исключает появлению случайных ошибок, обыкновенно присущих ручной обработке. Напротив, программные ошибки (или другие систематические ошибки в аппаратных либо программных средствах) приводят к неправильной обработке всех идентичных операций при одинаковых условиях. Разделение функций. Компьютерная система может осуществить множество процедур внутреннего контроля, которые в неавтоматизированных системах выполняют разные специалисты. Такая ситуация оставляет специалистам, имеющим доступ к компьютеру, возможность вмешательства в другие функции. В итоге компьютерные системы могут потребовать введения дополнительных мер для поддержания контроля на необходимом уровне, который в неавтоматизированных системах достигается простым разделением функций. К подобным мерам может, относится система паролей, которые предотвращают действия, не допустимые со стороны специалистов, имеющих доступ к информации об активах и учетных документах через терминал в диалоговом режиме. Потенциальные возможности появления ошибок и неточностей. По сравнению с неавтоматизированными системами бухгалтерского учета компьютерные системы более открыты для несанкционированного доступа, включая лиц, осуществляющих контроль. Они также открыты для скрытого изменения данных и прямого или косвенного получения информации об активах. Чем меньше человек вмешивается в машинную обработку операций учета, тем ниже возможность выявления ошибок и неточностей. Ошибки, допущенные при разработке или корректировке прикладных программ, могут оставаться незамеченными на протяжении длительного периода. Потенциальные возможности усиления контроля со стороны администрации. Компьютерные системы дают в руки администрации широкий набор аналитических средств, позволяющих оценивать и контролировать деятельность фирмы. Наличие дополнительного инструментария обеспечивает укрепление системы внутреннего контроля в целом и, таким образом, снижение риска его неэффективности. Так, результаты обычного сопоставления фактических значений коэффициента издержек с плановыми, а также сверки счетов поступают к администрации более регулярно при компьютерной обработке информации. Кроме того, некоторые прикладные программы накапливают статистическую информацию о работе компьютера, которую можно использовать в целях контроля фактического хода обработки операций бухгалтерского учета.
Глава II Технология эффективной автоматизации бухучета.
§ 1. Постановка целей и задач технологии
Сегодня пользователи деловых компьютерных программ исчисляются, наверное, сотнями тысяч. Как бы ни были хороши компьютеры и программы, среди такого количества людей всегда найдутся недовольные результатами автоматизации. Для рынка в целом процент неудачных проектов не столь велик. Но для каждого конкретного потребителя неудача порой оборачивается большими проблемами. Отметим, что и для поставщика программ неудачные проекты несут дополнительные хлопоты и подрывают репутацию. Проблемы и конфликты в ходе автоматизации никому не нужны. Так почему же они возникают? Анализ критических ситуаций показывает, что почти всегда виноваты не программы или компьютеры, а люди. Намного легче исправить программу, чем изменить точку зрения человека. К моменту конфликта в проект уже вложена уйма денег. Закрыть проект - значит, выбросить затраченные средства и силы на ветер. Но и дальше так продолжаться не может. К нам нередко обращаются по поводу экспертизы программы или проекта. Чаще всего с помощью экспертного заключения люди надеются доказать вину противоположной стороны. Но на самом деле, поиск виновных не разрешает проблему. Лучше всего, чтобы проблемы не возникало вовсе. Для этого очень важно уметь взглянуть на проект глазами другой стороны. Попробуем это сделать вместе. Сразу оговоримся, что случай действительно слабых и недоделанных программ мы здесь не рассматриваем. Многие потенциальные проблемы закладываются еще на этапе выбора программы или фирмы-разработчика. Приведем типичный пример. Тиражные недорогие бухгалтерские или торговые программы, имеющие наибольшую известность, рассчитаны, как правило, на небольшие и в отдельных случаях на средние предприятия. Их распространением занимаются дилеры. Такие программы всегда дешевые, иначе они не были бы массовыми. Доход от простой продажи таких программ невелик. Поэтому дилеры стараются заработать на услугах по внедрению и настройке, для чего они заключают контракт на комплексную автоматизацию. Сумма контракта обычно пропорциональна величине предприятия, и некоторые дилеры стараются заполучить клиента покрупнее - завод или даже холдинг. Но, как мы помним, программа-то рассчитана совсем на другой размер предприятия. В результате закладывается мина замедленного действия. Проблемы возникнут не сразу, а по мере ввода в эксплуатацию все новых и новых рабочих мест. Система начнет работать с непозволительными задержками. Возникнут проблемы с получением сводных результатов, с разграничением полномочий, со спецификой учета на отдельных участках и т.д. Как ни странно, но претензии заказчика могут возникнуть не к дилеру, а к разработчику и к его "плохой" программе. Но разработчик честно предупреждал в рекламе, в документации и даже в надписи на коробке, что программа ориентирована на такой-то размер и такой-то профиль деятельности предприятия. С точки зрения разработчика, виноват дилер и сам клиент. В нашей практике встречались случаи, когда корпорация ломала голову, что лучше выбрать систему R/3 или купить много программ "1С: Бухгалтерия". В первом случае проект обойдется в миллион долларов. Во втором - затраты уменьшатся на несколько порядков, а программы фирмы "1С" известны своим высоким качеством. Мы не утверждаем, что крупному предприятию всякий раз нужно покупать R/3 или "Галактику". Но выделяемые средства и рассматриваемые программы должны быть сопоставимы с масштабом поставленных задач. К числу ошибок клиента можно отнести также неуместную экономию на внедрении, настройке, обучении. Дорогостоящие программы внедряются собственными силами на протяжении долгих месяцев и в результате работают лишь на 5-10% своих возможностей. Зачастую подводит желание быть полностью независимым от разработчика. Для этого приобретаются самые гибкие программы, чтобы можно было самостоятельно настроиться на любые изменения в законодательстве. Но ирония состоит в том, что для такой настройки привлекаются случайные программисты, зависимость от которых еще хуже, чем от разработчика или официального дилера. Предположим, что выбор сделан. Выбрана и установлена достойная программа. При этом контракт предусматривает обучение, но к началу опытной эксплуатации персонал заказчика понятия не имеет, как работать с системой. Директор и главный бухгалтер сами программу не выбирали, но они были в курсе, что на проект затрачены немалые деньги. Они почти поверили в то, что автоматизация - это не модное веяние, а приносящее результат дело. Вдруг оказывается, что компьютеры и программы стоят сами по себе, а персонал работает по старинке. С точки зрения этих руководителей, во всем виноваты разработчики. Им заплачены деньги, а результата нет. По мнению разработчиков, виноват заказчик, который не только не смог организовать процесс обучения, но и вообще не желал прилагать никаких организационных усилий. Переход на компьютерный учет для крупного и даже среднего предприятия - это очень непростой процесс, требующий пересмотра буквально всех привычных операций, проведения ревизии всех документов, сверхурочной работы персонала, двойной нагрузки от параллельного ведения ручного и компьютерного учета. Без железной воли руководства такой процесс не может быть проведен в сжатые сроки. А растягивание этого процесса во времени может отбить желание к автоматизации у любого сотрудника. Каждое достаточно крупное предприятие по-своему уникально. Начиная от способа распределения учетных функций между персоналом и заканчивая тем, как территориально расположены рабочие места с компьютерами и каким образом они соединены в сеть. Автоматизация зачастую ведется поэтапно и в целях экономии предварительное полномасштабное обследование не проводится. Поэтому через год - другой после начала работ вдруг выясняется, что производительность уже выбранной системы недостаточна. Прикладная разработка вполне хороша с точки зрения набора функций, но инструментальная платформа слабовата. Разработчик утверждает, что необходимо переходить на Oracle и докупить несколько более мощных компьютеров. Но заказчик не согласен нести дополнительные расходы. Таким образом, вновь возникает патовая ситуация. Предположим, что проект доведен до логического конца. Система установлена, доработана, персонал обучен. Но накануне сдачи проекта выясняется, что, по мнению заказчика, ряд задач решен не так. Исполнитель в свою очередь утверждает, что по результатам опытной эксплуатации эти задачи были признаны полностью соответствующими требованиям технического задания. В чем же дело? Просто само задание было составлено давно и его авторы уволились. Отдельные элементы комплекса вполне удовлетворяют отдельных пользователей. Но кто-то должен принять все в целом. Для этого заказчик срочно назначает нового ответственного, который совсем не в курсе дел. Ответственный в целях подстраховки начинает придумывать новые требования, чтобы оттянуть момент подписания акта приемки. Еще чаще нам приходилось сталкиваться с проблемами, возникающими по причине смены руководства. В этом случае почти всегда меняются цели, стратегия, а иногда даже и направление деятельности. Разработчики в это время заканчивают последний этап автоматизации и неожиданно обнаруживают, что результат их труда безнадежно устарел. Надо сказать, что чаще всего новое руководство в таких случаях не имеет претензий к разработчикам, но и доводить до конца проект тоже не соглашается. Нередко оно настаивает на установке иной программы, более знакомой им по месту предыдущей работы. Персонал предприятия, потративший полгода на освоение и запуск одной программы, естественно, не хочет еще полгода осваивать другую. Кстати, чем комплексным бывает внедрение программ, тем труднее ее заменить. На одном крупном пивном заводе долгое время внедряли отечественную разработку. Разработчики вместе с аудиторами выступали при этом еще и в роли консультантов по постановке учета и финансового планирования. Проект был удачно завершен. Но через полтора года завод был перекуплен иностранцами, которые настояли на покупке западной программы вместо российской. А еще через 10 месяцев тщетных усилий по ее внедрению вновь вернулись к отечественной разработке. Как объяснили нам аудиторы, весь учет и едва ли не все управленческие технологии на заводе были построены под ту первую российскую программу. Сменить программу было невозможно без смены всей технологии учета и управления. А западную программу не выбросили. Раз или два в году с ее помощью печатали некие справки для иностранных совладельцев. Мы привели лишь несколько примеров, обозначив в каждом случае причину возникновения проблемы и мнение каждой стороны. Разобравшись с причиной любой конфликт можно преодолеть. При одном условии - для этого должна быть добрая воля обеих сторон. Но в жизни, в отличие от статьи, каждый чаще видит только свою правоту. На прошедшем недавно собрании ведущих российских разработчиков деловых программ затрагивалась, в том числе и эта проблема. Мы рассказали о наших шагах по защите интересов потребителя и нейтрализации конфликтов. Фирмы со своей стороны изъявили готовность предпринять ряд мер по предотвращению потенциальных конфликтов. Например, одна из таких мер - обмен информацией о недобросовестных дилерах. Была затронута и роль прессы в просвещении потенциальных потребителей, в знакомстве их с существующими видами программных продуктов, в объяснении важности более серьезного и ответственного подхода к автоматизации.