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