Выбор системы без участия консультантов
В принципе при выборе автоматизированной системы совсем
не обязательно участие консультантов. Нужно только взвешенно
и трезво подходить к этому вопросу и заранее сформулировать для себя важные критерии. Основной критерий выбора системы — ее
функциональная полнота. Система должна автоматизировать все
основные операции учета на предприятии, а также, возможно,
некоторые специфические операции, характерные для конкрет-
ных типов предприятий (банков, торговых, страховых, посредни-
ческих компаний, промышленных предприятий и т.д.). Большин-
ство предлагаемых на российском рынке систем автоматизации
имеют приемлемую функциональную полноту. При этом на пер-
вый план выходят другие параметры оценки системы.
Исходя из логики системного анализа, можно достаточно лег-
ко сформулировать ряд критериев выбора системы автоматизации
для предприятия. Эти критерии являются глобальными, т.е. го-
дятся практически для всех случаев. Существуют и локальные
критерии, достаточно специфичные для каждого типа предприя-
тий, которые мы здесь рассматривать не будем. Итак, пять правил
выбора информационной системы.
Правило 1. СИСТЕМА ДОЛЖНА БЫТЬ ПОНЯТНОЙ.
Важнейший критерий выбора системы — это возможность по-
нимания принципов ее работы конкретным бухгалтером или дру-
гим специалистом. Очевидно, что после изучения рекламного про-
спекта или просмотра демонстрационной версии программы на
условном примере фирмы-разработчика нельзя получить полное
представление об ее возможностях. Необходимо вникнуть в систе-
му, «почувствовать» ее.
Для достижения этой цели лучше всего попробовать начать
работать с программой «с нуля» на своем собственном небольшом
примере. Этот пример должен быть подготовлен заранее и в него
следует включить все основные типы операций.
Очевидно, что солидная фирма-разработчик должна достаточ-
но легко согласиться на подобное тестирование, а вот заявления
типа «сначала купите, потом тестируйте» должны насторожить.
Если автоматизация важнейших участков учета на собственном
примере при помощи выбранной системы идет успешно и техноло-
гия выполнения всех операций не вызывает трудностей, можно
считать, что система в целом понятна пользователю.
Правило 2. СИСТЕМА ДОЛЖНА БЫТЬ УДОБНОЙ.
Следующий важный момент при выборе системы — удобный
интерфейс с пользователем. Сегодня в России среди реально рабо-
тающих на предприятиях менеджеров можно встретить и бывше-
го профессионального программиста, и бывшего школьного учи-
теля словесности. Люди различаются по возрасту, квалификации, стажу работы и многим другим параметрам. Кто-то только начи-
нает работать на компьютере, а кто-то уже делает это много лет.
Именно поэтому нельзя говорить о том, что данная система удоб-
на для работы в целом.
Выбираемая система может считаться удобной только тогда,
когда она удобна для конкретного человека. Именно он определя-
ет степень удобности той или иной автоматизированной системы
и эта оценка должна быть решающей.
Так как все люди разные, то и оценки комфортности работы с
той или иной системой у них неодинаковые. Одни (в первую оче-
редь, пожилые и неискушенные пользователи) скорее всего выбе-
рут простую и понятную систему, а сложную работу захотят сделать
вручную. Другие (более молодые и уже знакомые с компьютером)
предпочтут пусть и сложную в эксплуатации систему, зато с боль-
шими функциональными возможностями. Не исключен и путь по-
степенного усиления системы по мере роста компьютерной квали-
фикации специалиста. Зато противопоказан обратный подход: «ку-
пим сложную систему, а людей потом научим». Такое решение
может привести к настоящей катастрофе, и виноват в этом будет не
исполнитель, а тот начальник, который ему эту систему навязал.
Довольно распространен еще один неверный подход к автома-
тизации на предприятиях: подбор персонала под систему. Часто
можно встретить рекламу типа: «... требуется специалист, умею-
щий работать в системе...». А как до приема на работу проверить
реальные знания кандидата? Как узнать, будет ли данная система
удобна в его работе? При поступлении на должность кандидат ска-
жет что угодно, а дальше начнутся проблемы. Итак, система под-
бирается под человека и должна быть удобна для него.
Правило 3. СИСТЕМА ДОЛЖНА БЫТЬ НАДЕЖНОЙ.
Проблему надежности системы автоматизации нужно прежде
всего правильно понимать. В принципе любая система ненадежна,
так как компьютер воспринимает абсолютно одинаково и милли-
оны долларов, и копейки: любая информация для компьютера не
более чем последовательность электрических сигналов или, если
перевести на язык информатики, нулей и единиц. Программа, если
она хоть как-то тестирована (впрочем, известны случаи, когда на
рынок выбрасывались системы, вообще неспособные отличить сим-
вольную информацию от числовой), будет защищать Вас от грубых
ошибок. Однако, это не означает, что в системе предусмотрены так-
же интеллектуальные средства анализа и защиты информации.
Как же следует оценивать выбираемую систему с позиций надеж
ности? Эта задача распадается на три самостоятельных части.
Во-первых, система должна отслеживать все виды случайных
ошибок, нарушающих ведение учета. Например, абсолютно недо-
пустима «полупроводка», когда сумма проводится по дебету одно-
го счета и не отражается по кредиту другого. Или наоборот. Не
должно быть разночтения курсов иностранных валют к рублю в
течение одного дня и т.д.
Во-вторых, в системе должны быть предусмотрены средства
защиты от случайной или намеренной порчи информации. Ины-
ми словами, система обязана либо проинформировать вас о воз-
можности потери информации, либо отказаться выполнять запре-
щенную операцию. Кроме того, желательны средства защиты от
несанкционированного доступа.
Наконец, система должна быть устойчива к сбоям и поломке
оборудования. Здесь возможны разные решения: автоматическое
сохранение базы данных в процессе работы, обязательная выгруз-
ка копии на дискеты или стример, специальные средства восста-
новления данных. Важно, чтобы эти средства существовали и ра-
ботали.
Оценку надежности системы, как и ее понятности, лучше все-
го проводить при помощи собственного тестирования. Попросите
разрешить вам самостоятельно поработать с системой и попробуй-
те несколько раз «ошибиться». В зависимости от результатов тес-
та можно сделать первые выводы о надежности системы. Не менее
важно задать представителю фирмы-разработчика вопрос о на-
дежности и попросить продемонстрировать реакцию системы на
ошибку или сбой на примере (лучше подготовленном Вами). Отказ
разработчиков от такой демонстрации позволит сделать необходи-
мые выводы, а в случае согласия вы все увидите сами.
Правило 4. СИСТЕМА ДОЛЖНА БЫТЬ АДЕКВАТНОЙ.
Как уже отмечалось, переходная экономика характеризуется
обилием изменений в правилах бухгалтерского учета и отчетнос-
ти. В этих условиях приобретаемая автоматизированная система
достаточно быстро может оказаться неадекватной текущему поло-
жению дел. Возможны два пути решения этой проблемы.
Первый путь является достаточно традиционным: фирма-раз-
работчик готовит новую версию системы и заменяет ей старую.
Ключевые моменты такой технологии: стоимость обновления вер-
сии, понятность и надежность новой версии, способ поставки но-
вой версии пользователю, частота смены версий.
Солидные компании заботятся о своих клиентах, что выража-
ется в развитой системе скидок на замену версий (upgrade), свое-
временной подготовке адаптированных руководств пользователя системы, обеспечении телефонных консультаций по «горячей ли-
нии» и т.д. Слабые разработчики эти услуги обеспечить не могут,
и их клиенты часто «зависают», так как не могут использовать
уже неадекватную реальной жизни систему.
Второй путь предполагает настройку системы в соответствии текущими требованиями. Это означает, что система изначально разрабатывается как легко адаптируемая, мобильная и гибкая.
Такой подход к разработке требует создания в системе определен-
ной избыточности функциональных возможностей, что делает ее
несколько более сложной при эксплуатации. Позитивным при та-
ком методе внесения изменений в систему является отсутствие
частой смены версий, а негативным — усложнение работы бухгал-
тера с компьютером ввиду необходимости самостоятельной настройки системы.
Есть еще одно решение, смысл которого заключается в посто-
янном или периодическом сопровождении системы со стороны
работников фирмы-разработчика. Для этого в структуру постав-
ляющей систему компании включаются выездные бригады кон-
сультантов или создаются филиалы в наиболее важных регионах.
Как правило, работа специалистов разработчика на выезде стоит весьма дорого и может значительно превышать стоимость самой, компьютерной программы, поэтому перед решением о приобретении системы с сопровождением целесообразно произвести расчет
всех будущих затрат.
Правило 5. РАЗРАБОТЧИК ДОЛЖЕН БЫТЬ СОЛИДНЫМ.
Очень опасно приобретать систему у несолидной фирмы: это может привести к настоящей катастрофе! Оценка солидности фирмы по обилию рекламы или активности на выставке не всегда может оказаться правильной, поэтому представляется целесообраз-
ным перед визитом в компанию, поставляющую на рынок пригля-
нувшуюся вам по другим характеристикам систему, собрать о ней
дополнительную информацию. Выделим несколько критериев
оценки солидности фирмы-разработчика:
— стаж работы фирмы на рынке;
— количество проданных копий или успешных случаев внедрения системы (всего и за последний год);
— цена системы (очень низкие и очень высокие цены одинаково опасны);
— наличие или отсутствие поддержки системы, виды поддер-
жки («горячая линия», консультации в офисе фирмы, выез-
дные консультации, собственные службы внедрения и т.д.);
— наличие или отсутствие учебных центров;
— отзывы пользователей, уже купивших эту систему;
— другая деятельность фирмы.
Используя перечисленные выше правила (а, может быть, свои
собственные критерии оценки фирм-разработчиков и их программ-
ных продуктов) можно самостоятельно выбирать систему автомати-
зации. Как уже отмечалось, информацию по системам можно полу-
чить на специализированных выставках и семинарах, презентаци-
ях компаний, непосредственно при визите в компанию,
поставляющую на рынок системы.
Читайте также:
Воспользуйтесь поиском по сайту: